Re: type inheritance in CIL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/29/2015 03:25 PM, Dominick Grift wrote:
On Mon, Jun 29, 2015 at 02:56:34PM -0400, James Carter wrote:
On 06/29/2015 07:19 AM, Miroslav Grepl wrote:
On 06/29/2015 09:56 AM, Dominick Grift wrote:
On Mon, Jun 29, 2015 at 09:29:34AM +0200, Miroslav Grepl wrote:
Trying to make sandbox working using CIL but I see it does not
support typeinherit statement.

One of those features that really define CIL but that is currently
not available or fully working yet.


Inheritance in CIL is handled with blocks.

The following policy:

(block b1
   (type t)
   (allow t self (CLASS (PERM)))
)

(block b2
   (blockinherit b1))

Would result in two types (b1.t and b2.t) and two rules.

See block_test.cil and name_resolution_test.cil in secilc/test/ for more
examples. Everything should work, but, of course, it has seen less testing
at this point.

Thanks I am aware of that featurew, namespacing is also still a bit buggy in my view though.

If this is meant to be a substitute for typeinherit then how is one supposed to implement something that behaves like typeinheritfilter?

You are aware the typeinherit and typeinheritfilter are still documented on https://github.com/SELinuxProject/cil/wiki?

Yes, although it has been a while since I looked at that.

The blockinherit is a substitute for typeinherit. There is no replacement for typeinheritfilter yet.

We would like to add a mechanism to remove rules at some point. But there are all sorts of potential ordering issues when you add something like that and we have been busy with other parts of CIL.

Jim


Jim

My suggestion is to study the "cilpolicy" (which is really just a
snapshot of reference policy transformed to cil with hll i
believe)

This will give you some pointers as to how to create an alternative
implementation that achieves a similar result.

When you write CIL policy, there are some "bugs" to take into
account and to workaround.


Sure there are different ways how to write it. I just wanted to
combine it with the current Fedora policy as much as possible without
re-writing the current Fedora policy.


-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red
Hat, Inc. _______________________________________________ Selinux
mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to
Selinux-leave@xxxxxxxxxxxxx. To get help, send an email
containing "help" to Selinux-request@xxxxxxxxxxxxx.



_______________________________________________ Selinux mailing
list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to
Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing
"help" to Selinux-request@xxxxxxxxxxxxx.





--
James Carter <jwcart2@xxxxxxxxxxxxx>
National Security Agency
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



--
James Carter <jwcart2@xxxxxxxxxxxxx>
National Security Agency
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux