Update to CIL

Update to CIL

[James Carter]

I pushed an update of CIL to bitbucket.

Richard Haines submitted a patch to allow specifying the file contexts file. 
Other than that, the changes were bug fixes or minor cleanups.

Among the bug fixes:

Fixed the following issues with CIL first found by Richard Haines:

- Bug in constraint handling that caused them to be left out of the kernel policy.
- Role and type attributes in constraints were not being expanded.
- block_node was not being initialized before use in cil_resolve_blockabstract.
- The value of CIL_KEY_CONS_T3 should be "u3" rather than "us" in cil_internal.h.

Fixed the following issue first found by Dominick Grift:

- Bug where categories show up in a non-mls kernel policy.


Thank you to those who have been trying CIL out.


Anyone interested in trying CIL out can do the following:

1) Clone the CIL compiler and cilpolicy
git clone https://jwcarter@bitbucket.org/jwcarter/secilc.git
git clone https://jwcarter@bitbucket.org/jwcarter/cilpolicy.git

2) Build secilc
cd secilc
make
cd ..

3) Build cilpolicy
./secilc/secilc `cat cilpolicy/LISTING`


To build an MLS policy:

Edit "cilpolicy/mls_declarations" and change "(tunable enable_mls false)" to 
"(tunable enable_mls true)"

Build the MLS policy: ./secilc/secilc -M `cat cilpolicy/LISTING`

MCS is similar.


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> I pushed an update of CIL to bitbucket.

I had to do this, to make it compile ( not sure what i might have broken
by doing this ):

--- a/src/cil.c
+++ b/src/cil.c
@@ -1493,7 +1493,6 @@ void cil_userbounds_init(struct cil_userbounds
**userbounds)
        *userbounds = cil_malloc(sizeof(**userbounds));
 
        (*userbounds)->user_str = NULL;
-       (*userbounds)->user = NULL;
        (*userbounds)->bounds_str = NULL;
 }

Also a thing i noticed, which is unrelated to secilc, but related to
cilpolicy is that object_r role is associated to identities.

The object_r string is not really a role, although it looks like it.

Its just a string that is used as a place holder for the role security
attribute of objects.

Anyhow, i am going to write a minimum policy with secilc tomorrow i
think, so maybe then i will find new bugs, insights.

Thanks for your work


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 22:02 +0200, Dominick Grift wrote:
> On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> > I pushed an update of CIL to bitbucket.
> 
> I had to do this, to make it compile ( not sure what i might have broken
> by doing this ):
> 
> --- a/src/cil.c
> +++ b/src/cil.c
> @@ -1493,7 +1493,6 @@ void cil_userbounds_init(struct cil_userbounds
> **userbounds)
>         *userbounds = cil_malloc(sizeof(**userbounds));
>  
>         (*userbounds)->user_str = NULL;
> -       (*userbounds)->user = NULL;
>         (*userbounds)->bounds_str = NULL;
>  }
> 
> Also a thing i noticed, which is unrelated to secilc, but related to
> cilpolicy is that object_r role is associated to identities.
> 
> The object_r string is not really a role, although it looks like it.
> 
> Its just a string that is used as a place holder for the role security
> attribute of objects.
> 
> Anyhow, i am going to write a minimum policy with secilc tomorrow i
> think, so maybe then i will find new bugs, insights.
> 
> Thanks for your work
> 

Been playing with this today and so far so good except for a few things:

Not sure if its due to my incompetence or due to the line i removed
( see above) from cil.c, login programs (pam) is not able to get a valid
context for my users. I believe i set all the associations up properly

I noticed that no matter if you just want to create a default policy
model, you always have to take the option security models (MLS/MCS) into
account at least to some degree. For example you need to specify current
and clearance with filecon even if you wish to not use use MLS/MCS

Another thing i noticed which is loosely related is that if you build a
mcs policy, and install it, then run restorecon -R -v -F, it will reset
contexts using current and clearance (it has s0-s0 specified in
file_contexts) no matter how many times you run it. It will always reset
from s0 to s0-s0

As said above already, i now also encountered the object_r issue myself:
it sucks. One needs to allow object_r role access to all types...
object_r is not even a role (or atleast it should not be AFAIK)

Lastly i have to get used to the cil syntax, The documentation is a bit
inaccurate. For example it seems that typeattributetypes was renamed to
typeattributeset. 

I was trying to associate 3 types to a single type attribute and i first
encountered typeattribute set, and the example showed how its supposed
to be used with "and or xor not", and so i tried that, but it turned out
you can only associate two types to a type attribute using any of those
keywords

Later on i stumbled upon typeattributetypes, and the examples looked
promissing. it mentioned that you can use it to associate more types to
the attribute with it. But when i tried it, it turned out it no longer
existed.

However, i tied the strings together and managed to associate 3 types to
a single type attribute using the typeattributetypes example with the
typeattributeset statement.

Also i was not able to write TE AV rules with two target types. e.g.
where we previously used brace expansion: allow bla_t { foo_t
bar_t }:file read;

I tried several things like: (allow (bla_t ( foo_t bar_t))
all_file_perms), but no go

It is just a matter of getting used to the new way of doing things, but
i feel that its very powerful, and i like it alot.

Also secilc seems nice and fast, especially if it also takes care of the
neverallow rules (doing that with semodule link/expand takes ages)

So, yea, the only pressing issue now for me is to get my users to log
in. I have created a nice minimal policy today with cil and other than
this issue it works great!

>    Classes:            54    Permissions:       193
>    Sensitivities:       1    Categories:       1024
>    Types:               4    Attributes:          1
>    Users:               1    Roles:               2
>    Booleans:            0    Cond. Expr.:         0
>    Allow:              54    Neverallow:          0
>    Auditallow:          0    Dontaudit:           0
>    Type_trans:          0    Type_change:         0
>    Type_member:         0    Role allow:          0
>    Role_trans:          0    Range_trans:         0
>    Constraints:         0    Validatetrans:       0
>    Initial SIDs:       27    Fs_use:             23
>    Genfscon:           84    Portcon:             2
>    Netifcon:            0    Nodecon:             0
>    Permissives:         0    Polcap:              2




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Richard Haines]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

Thanks for the update. I added the fix used by Dominick and tested the various
fixes that are now okay. However (sorry) but one new bug has been introduced
and some others are still present:

1) New bug - I've been using tunables to select the different levels of
   support between Tresys and NSA compilers. Since this update, mapping
   inside tunables does not work (but only when using classpermissionset).
   The "tunable-mapping-error.cil" module demos this error.

2) classmapping only takes the first entry whether in a boolean or not. The
   "map-perm-error.cil" module demos this error. The Tresys compiler has
   a different problem - see text in "map-perm-error.cil".

3) Fails to resolve neverallow "*". The "neverallow-STAR.cil" module demos
   this error.

4) Not sure if this is a bug or 'as designed', I tried using "in" in a
   booleanif statement but failed. The "in-boolean.cil" module demos
   this error.

These only apply to the Tresys compiler (as do 2, 3, & 4):
5) Does not expand all entries in a typeattribute for allow rules within
   a boolean. The "ta-bool-error.cil" module demos this error.

6) Neverallow fails when rule defined in a dontaudit rule. The NSA compiler
   and checkpolicy do not generate an error.  The "neverallow-error.cil" 
   module demos this error.

The attached "cil-base.cil" supplies the user, role etc. requirements

Finally I know the NSA version resolves constraints okay now, but the output
is reversed in Tresys. The "mlsconstrain-diff.cil" shows the difference but
in the end they resolve to the same. I have not tried complex constraints.

Hope all this helps
Richard

[-- Attachment #2: cil-base.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 813 bytes --]

[-- Attachment #3: in-boolean.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 983 bytes --]

[-- Attachment #4: map-perm-error.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 2361 bytes --]

[-- Attachment #5: mlsconstrain-diff.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 1426 bytes --]

[-- Attachment #6: neverallow-error.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 1251 bytes --]

[-- Attachment #7: neverallow-STAR.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 1065 bytes --]

[-- Attachment #8: ta-bool-error.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 2131 bytes --]

[-- Attachment #9: tunable-mapping-error.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 1778 bytes --]

Re: Update to CIL

[Dominick Grift]

On Sat, 2013-10-19 at 15:32 +0200, Dominick Grift wrote:

> Been playing with this today and so far so good except for a few things:
> 
> Not sure if its due to my incompetence or due to the line i removed
> ( see above) from cil.c, login programs (pam) is not able to get a valid
> context for my users. I believe i set all the associations up properly

i think libselinux is broken (again) in Fedora:

https://www.youtube.com/watch?v=eKbzSCGL3V4


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Sat, 2013-10-19 at 20:03 +0200, Dominick Grift wrote:
> On Sat, 2013-10-19 at 15:32 +0200, Dominick Grift wrote:
> 
> > Been playing with this today and so far so good except for a few things:
> > 
> > Not sure if its due to my incompetence or due to the line i removed
> > ( see above) from cil.c, login programs (pam) is not able to get a valid
> > context for my users. I believe i set all the associations up properly
> 
> i think libselinux is broken (again) in Fedora:
> 
> https://www.youtube.com/watch?v=eKbzSCGL3V4
> 

never mind: i fixed this by, i guess, moving the default_contexts file
from /etc/selinux/mycil/contexts/files to /etc/selinux/mycil/contexts/


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Steve Lawrence]

On 10/18/2013 04:02 PM, Dominick Grift wrote:
> On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
>> I pushed an update of CIL to bitbucket.
>
> I had to do this, to make it compile ( not sure what i might have broken
> by doing this ):
>
> --- a/src/cil.c
> +++ b/src/cil.c
> @@ -1493,7 +1493,6 @@ void cil_userbounds_init(struct cil_userbounds
> **userbounds)
>          *userbounds = cil_malloc(sizeof(**userbounds));
>
>          (*userbounds)->user_str = NULL;
> -       (*userbounds)->user = NULL;
>          (*userbounds)->bounds_str = NULL;
>   }
>
> Also a thing i noticed, which is unrelated to secilc, but related to
> cilpolicy is that object_r role is associated to identities.
>
> The object_r string is not really a role, although it looks like it.
>

It is a role, it's just one that has been created and associated with 
all types by default, so you've never needed to do it before in 
refpolicy. In an attempt to make CIL consistent and to prevent errors in 
policy, you now need to create and associate object_r just like you 
would any other role.

> Its just a string that is used as a place holder for the role security
> attribute of objects.
>
> Anyhow, i am going to write a minimum policy with secilc tomorrow i
> think, so maybe then i will find new bugs, insights.
>
> Thanks for your work
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Steve Lawrence]

On 10/19/2013 09:32 AM, Dominick Grift wrote:
> On Fri, 2013-10-18 at 22:02 +0200, Dominick Grift wrote:
>> On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
>>> I pushed an update of CIL to bitbucket.
>>
>> I had to do this, to make it compile ( not sure what i might have broken
>> by doing this ):
>>
>> --- a/src/cil.c
>> +++ b/src/cil.c
>> @@ -1493,7 +1493,6 @@ void cil_userbounds_init(struct cil_userbounds
>> **userbounds)
>>          *userbounds = cil_malloc(sizeof(**userbounds));
>>
>>          (*userbounds)->user_str = NULL;
>> -       (*userbounds)->user = NULL;
>>          (*userbounds)->bounds_str = NULL;
>>   }
>>
>> Also a thing i noticed, which is unrelated to secilc, but related to
>> cilpolicy is that object_r role is associated to identities.
>>
>> The object_r string is not really a role, although it looks like it.
>>
>> Its just a string that is used as a place holder for the role security
>> attribute of objects.
>>
>> Anyhow, i am going to write a minimum policy with secilc tomorrow i
>> think, so maybe then i will find new bugs, insights.
>>
>> Thanks for your work
>>
>
> Been playing with this today and so far so good except for a few things:
>
> Not sure if its due to my incompetence or due to the line i removed
> ( see above) from cil.c, login programs (pam) is not able to get a valid
> context for my users. I believe i set all the associations up properly

Sounds like you've figure out this problem.

> I noticed that no matter if you just want to create a default policy
> model, you always have to take the option security models (MLS/MCS) into
> account at least to some degree. For example you need to specify current
> and clearance with filecon even if you wish to not use use MLS/MCS

We want to avoid optional arguments to and CIL statements. Because of 
this, the mls/mcs arguments are required, even when building non-mls/mcs 
policies.

> Another thing i noticed which is loosely related is that if you build a
> mcs policy, and install it, then run restorecon -R -v -F, it will reset
> contexts using current and clearance (it has s0-s0 specified in
> file_contexts) no matter how many times you run it. It will always reset
> from s0 to s0-s0

This should be easy enough to fix. If the low and high levels are the 
same, then we'll just output the low.

> As said above already, i now also encountered the object_r issue myself:
> it sucks. One needs to allow object_r role access to all types...
> object_r is not even a role (or atleast it should not be AFAIK)

True, but this actually isn't going to be bad. The majority of types are 
going to be associated with an attribute, and usually through a macro, e.g.:

   (type foo_t)
   (call files_type (foo_t))

Either the files_type macro could perform the object_r association:

   (macro files_type ((type t))
     (typeattributeset file_type t)
     (roletype object_r t))

or you could just associate object_r with the attribute somewhere else:

   (roletype object_r (file_type))

> Lastly i have to get used to the cil syntax, The documentation is a bit
> inaccurate. For example it seems that typeattributetypes was renamed to
> typeattributeset.

Yes, the documentation is lacking right now. There are still ongoing 
discussions on changes to the CIL syntax. As things settle down, we 
should be able to put some focus towards improving the documentation. 
Right now, the best source is probably Jim's cilpolicy.git repo.

> I was trying to associate 3 types to a single type attribute and i first
> encountered typeattribute set, and the example showed how its supposed
> to be used with "and or xor not", and so i tried that, but it turned out
> you can only associate two types to a type attribute using any of those
> keywords

I believe you can associate more than one type via the following:

   (typeattributeset attr (type1 type2 type3))

But, typeattributeset is one of the syntax changes we are discussing. As 
you mentioned, you can only associate two types to a type attribute 
using expressions. This is going to change. Of course it requires adding 
more parenthesis, but we already have a ton of those, so what's one more 
set.

> Later on i stumbled upon typeattributetypes, and the examples looked
> promissing. it mentioned that you can use it to associate more types to
> the attribute with it. But when i tried it, it turned out it no longer
> existed.

Yes, we replaced typeattributetypes with typeattributeset.

> However, i tied the strings together and managed to associate 3 types to
> a single type attribute using the typeattributetypes example with the
> typeattributeset statement.
>
> Also i was not able to write TE AV rules with two target types. e.g.
> where we previously used brace expansion: allow bla_t { foo_t
> bar_t }:file read;

Yes, the source/target parameters of the allow rule only allow a single 
type or typeattribute. CIL is not meant to be succinct. You'll find 
there's a great deal of repetition. The idea is that higher level 
languages would allow for succinctness.

> I tried several things like: (allow (bla_t ( foo_t bar_t))
> all_file_perms), but no go

If you really don't want two allow rules, you can create a typeattribute:

   (typeattribute foobar)
   (typeattributeset foobar (foo_t bar_t))
   (allow bla_t foobar all_file_perms)

But unless the foobar attribute has some kind of meaning, it probably 
makes more sense to just have two allow rules.

> It is just a matter of getting used to the new way of doing things, but
> i feel that its very powerful, and i like it alot.
>
> Also secilc seems nice and fast, especially if it also takes care of the
> neverallow rules (doing that with semodule link/expand takes ages)

It does check neverallow rules.

> So, yea, the only pressing issue now for me is to get my users to log
> in. I have created a nice minimal policy today with cil and other than
> this issue it works great!
>
>>     Classes:            54    Permissions:       193
>>     Sensitivities:       1    Categories:       1024
>>     Types:               4    Attributes:          1
>>     Users:               1    Roles:               2
>>     Booleans:            0    Cond. Expr.:         0
>>     Allow:              54    Neverallow:          0
>>     Auditallow:          0    Dontaudit:           0
>>     Type_trans:          0    Type_change:         0
>>     Type_member:         0    Role allow:          0
>>     Role_trans:          0    Range_trans:         0
>>     Constraints:         0    Validatetrans:       0
>>     Initial SIDs:       27    Fs_use:             23
>>     Genfscon:           84    Portcon:             2
>>     Netifcon:            0    Nodecon:             0
>>     Permissives:         0    Polcap:              2
>
>
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Steve Lawrence]

On 10/19/2013 12:23 PM, Richard Haines wrote:
> Thanks for the update. I added the fix used by Dominick and tested the various
> fixes that are now okay. However (sorry) but one new bug has been introduced
> and some others are still present:
>

Thanks for the bug reports and examples. Very helpful.

> 1) New bug - I've been using tunables to select the different levels of
>     support between Tresys and NSA compilers. Since this update, mapping
>     inside tunables does not work (but only when using classpermissionset).
>     The "tunable-mapping-error.cil" module demos this error.
>
> 2) classmapping only takes the first entry whether in a boolean or not. The
>     "map-perm-error.cil" module demos this error. The Tresys compiler has
>     a different problem - see text in "map-perm-error.cil".
>
> 3) Fails to resolve neverallow "*". The "neverallow-STAR.cil" module demos
>     this error.
>
> 4) Not sure if this is a bug or 'as designed', I tried using "in" in a
>     booleanif statement but failed. The "in-boolean.cil" module demos
>     this error.
>

This should not be allowed. The only thing that should be allowed in a 
booleanif statement are typetransitions, typerules, and avrules.


> These only apply to the Tresys compiler (as do 2, 3, & 4):
> 5) Does not expand all entries in a typeattribute for allow rules within
>     a boolean. The "ta-bool-error.cil" module demos this error.
>
> 6) Neverallow fails when rule defined in a dontaudit rule. The NSA compiler
>     and checkpolicy do not generate an error.  The "neverallow-error.cil"
>     module demos this error.
>

I would start only using Jim's repo. The changes to that repo have fixed 
many of the problems. It is what we are working on.

> The attached "cil-base.cil" supplies the user, role etc. requirements
>
> Finally I know the NSA version resolves constraints okay now, but the output
> is reversed in Tresys. The "mlsconstrain-diff.cil" shows the difference but
> in the end they resolve to the same. I have not tried complex constraints.
>
> Hope all this helps

Very helpful. Thanks!

> Richard
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Richard Haines]

>>  4) Not sure if this is a bug or 'as designed', I tried using 
> "in" in a
>>      booleanif statement but failed. The "in-boolean.cil" module 
> demos
>>      this error.
>> 
> 
> This should not be allowed. The only thing that should be allowed in a 
> booleanif statement are typetransitions, typerules, and avrules.
> 
> 
Regarding the allowed items - the 'call' statement is also allowed as I'm using it
already on both versions of the compiler so it seemed strange to exclude the 'in'
statement.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Steve Lawrence]

On 10/21/2013 10:22 AM, Richard Haines wrote:
>
>
>>>   4) Not sure if this is a bug or 'as designed', I tried using
>> "in" in a
>>>       booleanif statement but failed. The "in-boolean.cil" module
>> demos
>>>       this error.
>>>
>>
>> This should not be allowed. The only thing that should be allowed in a
>> booleanif statement are typetransitions, typerules, and avrules.
>>
>>
> Regarding the allowed items - the 'call' statement is also allowed as I'm using it
> already on both versions of the compiler so it seemed strange to exclude the 'in'
> statement.
>

Yes, you're correct, I forgot about the call statement. That is allowed 
in booleanif's, but that is because what basically happens with calls is 
that the contents of the macro are copied into the booleanif. This means 
that any macros called inside of a booleanif must only contain those 
statements I listed above.

However, the 'in' statment works kindof like a preprocessor macro in C, 
only it knows about CIL namespaces. And so the 'in' statement never 
makes it into the binary policy. This means that if we allowed 'in' 
statements in booleanifs and you disabled a boolean at runtime, we 
couldn't undo whatever changes the 'in' statement made, which is not 
likely what the user intended. For this reason, we do not allow the 'in' 
statement in booleanifs.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Request for a new CIL statement

[Richard Haines]

As CIL now seems to be under serious development, could I put forward a 
request for a new statement that would build variable length configuration
file entries. This would allow policy writers to build all required
configuration files to support the 'policy'. It would also allow the
parameters used to be validated by the build process. 

Currently CIL generates the file_contexts entries using the 'filecon'
statement, this method is okay for this application, however there are
files that require entries with a variable number of parameters (examples:
setrans.conf and seapp_contexts).

What I've been trying to achieve (and failing) is to generate entries like
these example seapp_contexts entries:
   isSystemServer=true domain=system_server.process
   user=_app seinfo=netclient domain=netclient_app.process type=netclient_app.log_file level=s0:c1020.c1023

A possible statement format could be:
(configfileentry filename "test string with %s for %s param" (type param1) (type param2) ...)       

Examples:
(configfileentry seapp_contexts "isSystemServer=true domain=%s" (type system_server.process))

(configfileentry seapp_contexts "user=_app seinfo=netclient domain=%s type=%s level=%s"
    (type netclient_app.process)
    (type netclient_app.log_file)
    (level s0:c1020.c1023))

The final process would be to assemble all entries for each configuration
filename and create the file (I'm not sure about sorting order but could be
left to the process that uses the config file).

I've been reworking the call/macro code to achieve this but I seem to be
allergic to compiler code for some reason.

If it does seem a worthwhile idea I'm happy to continue but will probably
require a few pointers.

Richard


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[James Carter]

On 10/21/2013 09:25 AM, Steve Lawrence wrote:
> On 10/19/2013 09:32 AM, Dominick Grift wrote:

>>
>> Also i was not able to write TE AV rules with two target types. e.g.
>> where we previously used brace expansion: allow bla_t { foo_t
>> bar_t }:file read;
>
> Yes, the source/target parameters of the allow rule only allow a single type or
> typeattribute. CIL is not meant to be succinct. You'll find there's a great deal
> of repetition. The idea is that higher level languages would allow for
> succinctness.
>
>> I tried several things like: (allow (bla_t ( foo_t bar_t))
>> all_file_perms), but no go
>
> If you really don't want two allow rules, you can create a typeattribute:
>
>    (typeattribute foobar)
>    (typeattributeset foobar (foo_t bar_t))
>    (allow bla_t foobar all_file_perms)
>
> But unless the foobar attribute has some kind of meaning, it probably makes more
> sense to just have two allow rules.
>

We wanted to prevent writing rules such as "allow foo_t { file_type -bar_t 
}:file read;" which expand into a large number of rules. Dan and others have 
converted a large number rules like this into ones using attributes which has 
really reduced the size of the binary policy. CIL requires what we believe to be 
the best practice.

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[James Carter]

On 10/19/2013 12:23 PM, Richard Haines wrote:
> Thanks for the update. I added the fix used by Dominick and tested the various
> fixes that are now okay. However (sorry) but one new bug has been introduced
> and some others are still present:
>
> 1) New bug - I've been using tunables to select the different levels of
>     support between Tresys and NSA compilers. Since this update, mapping
>     inside tunables does not work (but only when using classpermissionset).
>     The "tunable-mapping-error.cil" module demos this error.
>

I have noticed a problem with constraints in tunables not showing up as well.

> 2) classmapping only takes the first entry whether in a boolean or not. The
>     "map-perm-error.cil" module demos this error. The Tresys compiler has
>     a different problem - see text in "map-perm-error.cil".
>

I did know about this. We are going to be making some changes to classmappings 
and classpermissionsets, so this will be taken care of soon.

> 3) Fails to resolve neverallow "*". The "neverallow-STAR.cil" module demos
>     this error.
>

The "*" is currently seen to be an expression in CIL rather than as the name of 
a set that includes all types. We are making some changes to expression and list 
handling, so this could change. We have also been taking a look at using "all" 
instead of "*" (since we use names instead of symbols elsewhere in CIL).

At any rate, currently you would have to define a typeattributeset and use that 
in the neverallow.


Thanks for your help.

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> I pushed an update of CIL to bitbucket.

Not sure if this is useful but today i got secilc to segfault (due to my
incompetence needless to say)

This seems to have been faulty policy that cecilc could not handle
gracefully (i fixed the policy syntax error later):

> (classpermissionset nottransitionordyntransitionprocess (process (not
>             transition dyntransition)))

This was what happened:

> # ./examplepolicy.sh
> Invalid syntax
> Invalid expression syntax
> Bad expression tree
> Bad permission list or expression
> Bad class-permissions
> Problem filling class-permissions list
> Bad classpermissionset declaration at line 243 of /root/examplepolicy/policy/modules/kernel/kernel
> Failed to build AST
> Failed to build ast
> Failed to compile cildb: -1
> ./examplepolicy.sh: line 33:  2147 Segmentation fault      "$SECILC_PATH"/secilc -U allow -c "$POLICY_VERSION" -v --output="$POLICY_PATH"/policy."$POLICY_VERSION" --filecontext="$POLICY_PATH"/file_contexts `cat "$POLICY_PATH"/LISTING`




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[James Carter]

On 10/23/2013 09:59 AM, Dominick Grift wrote:
> On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
>> I pushed an update of CIL to bitbucket.
>
> Not sure if this is useful but today i got secilc to segfault (due to my
> incompetence needless to say)
>

It is useful, because bad syntax shouldn't cause a segfault. Thanks for the report.

> This seems to have been faulty policy that cecilc could not handle
> gracefully (i fixed the policy syntax error later):
>
>> (classpermissionset nottransitionordyntransitionprocess (process (not
>>              transition dyntransition)))
>
> This was what happened:
>
>> # ./examplepolicy.sh
>> Invalid syntax
>> Invalid expression syntax
>> Bad expression tree
>> Bad permission list or expression
>> Bad class-permissions
>> Problem filling class-permissions list
>> Bad classpermissionset declaration at line 243 of /root/examplepolicy/policy/modules/kernel/kernel
>> Failed to build AST
>> Failed to build ast
>> Failed to compile cildb: -1
>> ./examplepolicy.sh: line 33:  2147 Segmentation fault      "$SECILC_PATH"/secilc -U allow -c "$POLICY_VERSION" -v --output="$POLICY_PATH"/policy."$POLICY_VERSION" --filecontext="$POLICY_PATH"/file_contexts `cat "$POLICY_PATH"/LISTING`
>
>
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
>


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> I pushed an update of CIL to bitbucket.

I noticed that cilpolicy does not have refpolicies
"selinux_labeled_boolean" interface

I tried to implement it myself but i cannot get it to parse ARG2 no
matter what i try

This is what i currently have:

macro:

> ; Associate the specified type and name with booleans
> 
> (macro selinux_labeled_boolean ((type ARG1) (name ARG2))
>   (call selinux_boolean_type (ARG1))
>   (genfscon "selinuxfs" ARG2 (system_u object_r ARG1 ((s0)
>             (s0)))))

call:

> (type secure_mode_insmod_t)
> (call selinux_labeled_boolean (secure_mode_insmod_t
>              "/booleans/secure_mode_insmod"))

result:

> # seinfo --genfscon | grep secure_mode_insmod
>    genfscon selinuxfs ARG2      system_u:object_r:secure_mode_insmod_t

Is there a work around for this?

I realize that the nature of cil make these kind of things less useful
but it would have been nice if it worked




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[James Carter]

On 10/23/2013 11:15 AM, Dominick Grift wrote:
> On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
>> I pushed an update of CIL to bitbucket.
>
> I noticed that cilpolicy does not have refpolicies
> "selinux_labeled_boolean" interface
>

This interface causes many problems.

First, when trying to convert Refpolicy to CIL, the conversion program tries to 
infer parameter types (language types, not SELinux types). This interface causes 
an error because the parameter which is the boolean name is used as both a 
string and a boolean.

Second, the conversion program can't recognize general string concatenation 
(although it does specifically handle type mangling).

Third, CIL does not allow conversion from one language type to another.

Fourth, CIL does not have the ability to concatenate strings.

All of these problems could probably be worked around, but I would prefer not to 
have general string concatenation and language type conversions in CIL.

This is a perfect example of something that a higher-level language could 
provide. Although that doesn't help you now.

> I tried to implement it myself but i cannot get it to parse ARG2 no
> matter what i try
>
> This is what i currently have:
>
> macro:
>
>> ; Associate the specified type and name with booleans
>>
>> (macro selinux_labeled_boolean ((type ARG1) (name ARG2))
>>    (call selinux_boolean_type (ARG1))
>>    (genfscon "selinuxfs" ARG2 (system_u object_r ARG1 ((s0)
>>              (s0)))))
>
> call:
>
>> (type secure_mode_insmod_t)
>> (call selinux_labeled_boolean (secure_mode_insmod_t
>>               "/booleans/secure_mode_insmod"))
>
> result:
>
>> # seinfo --genfscon | grep secure_mode_insmod
>>     genfscon selinuxfs ARG2      system_u:object_r:secure_mode_insmod_t
>
> Is there a work around for this?
>

Sorry, there is not.

> I realize that the nature of cil make these kind of things less useful
> but it would have been nice if it worked
>
>


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[James Carter]

On 10/23/2013 11:58 AM, James Carter wrote:
> On 10/23/2013 11:15 AM, Dominick Grift wrote:
>> On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
>>> I pushed an update of CIL to bitbucket.
>>
>> I noticed that cilpolicy does not have refpolicies
>> "selinux_labeled_boolean" interface
>>
>
> This interface causes many problems.
>
> First, when trying to convert Refpolicy to CIL, the conversion program tries to
> infer parameter types (language types, not SELinux types). This interface causes
> an error because the parameter which is the boolean name is used as both a
> string and a boolean.
>
> Second, the conversion program can't recognize general string concatenation
> (although it does specifically handle type mangling).
>
> Third, CIL does not allow conversion from one language type to another.
>
> Fourth, CIL does not have the ability to concatenate strings.
>
> All of these problems could probably be worked around, but I would prefer not to
> have general string concatenation and language type conversions in CIL.
>
> This is a perfect example of something that a higher-level language could
> provide. Although that doesn't help you now.
>
>> I tried to implement it myself but i cannot get it to parse ARG2 no
>> matter what i try
>>
>> This is what i currently have:
>>
>> macro:
>>
>>> ; Associate the specified type and name with booleans
>>>
>>> (macro selinux_labeled_boolean ((type ARG1) (name ARG2))
>>>    (call selinux_boolean_type (ARG1))
>>>    (genfscon "selinuxfs" ARG2 (system_u object_r ARG1 ((s0)
>>>              (s0)))))
>>
>> call:
>>
>>> (type secure_mode_insmod_t)
>>> (call selinux_labeled_boolean (secure_mode_insmod_t
>>>               "/booleans/secure_mode_insmod"))
>>
>> result:
>>
>>> # seinfo --genfscon | grep secure_mode_insmod
>>>     genfscon selinuxfs ARG2      system_u:object_r:secure_mode_insmod_t
>>
>> Is there a work around for this?
>>
>
> Sorry, there is not.
>
>> I realize that the nature of cil make these kind of things less useful
>> but it would have been nice if it worked
>>

I am sorry. I got so caught up in the painful memories of having to deal with 
the selinux_labeled_boolean interface that I missed what you were actually 
trying to do.

What you want to do here is quite reasonable and we should make it possible in CIL.

Thanks again for the feedback.

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Wed, 2013-10-23 at 13:00 -0400, James Carter wrote:

> 
> I am sorry. I got so caught up in the painful memories of having to deal with 
> the selinux_labeled_boolean interface that I missed what you were actually 
> trying to do.
> 
> What you want to do here is quite reasonable and we should make it possible in CIL.
> 
> Thanks again for the feedback.
> 

I am not sure if it makes sense to make this work, as it sets a
precedence. I mean whats next: specify file contexts via macros?

The nature of CIL will make it easy to do this manually instead:

consider module "mybool":

> (type mybool_t)
> (call selinux_boolean_type (mybool_t))

> (genfscon "selinuxfs" "/booleans/mybool" (system_u object_r
>           mybool_t ((s0) (s0))))


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> I pushed an update of CIL to bitbucket.

Now that we can specify contraints in "loadable modules" i noticed that
i can alter the behavior of existing constraints in the sense that they
can be overridden

take for example this instance

in the domain module ( which i consider "base" ) i have this constraint:

> (constrain (process (transition dyntransition noatsecure siginh rlimitinh))
>            (or (or (or (eq u1 u2) (and (eq t1
>            can_change_process_identity) (eq t2 process_user_target)))
>            (and (eq t1 can_system_change) (eq u2 system_u)))
>            (eq t1 process_uncond_exempt)))
> 

This seems to work fine. however if i now want to extent this from a loadable
module. for example the cron module:

> (constrain (process (transition dyntransition noatsecure siginh rlimitinh))
>            (or (eq u1 u2) (and (eq t1 cron_source_domain) (or
>            (eq t2 cron_job_domain) (eq u2 system_u)))))


Then the former "base" constraint no longer works. Its not getting extended
but rather a new one gets added and now the first one fails because the second on
is not met

it would have been nice if cilc merged the two into a single constraint instead

In practice its not a big deal because the source policy is probably on the system
anyways so might as well put it in the domain module

But it would have been nice if i could put it in the module where it belongs so that when
i choose to disable the module, the module related constraint rules disappear as well

Is this a right assumption or are my constraints just wrong?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> I pushed an update of CIL to bitbucket.

Is it me or is the negator "not" not working here:

> (boolean secure_mode_insmod false)

> (booleanif (not secure_mode_insmod)
>   (true
>     (allow loadkernelmodule self (capability (sys_module sys_nice)))
>     (allow loadkernelmodule kernel_t (process (setsched)))))
> 


> (macro kernel_load_module ((type ARG1))
>   (typeattributeset loadkernelmodule ARG1))

> (call kernel_load_module (kernel_t))

> # getsebool -a | grep insmod
> secure_mode_insmod --> off


> # sesearch -ASCT -p sys_module | grep insmod
> ET allow kernel_t kernel_t : capability { sys_module sys_nice } ; [ secure_mode_insmod ! ]

> # ausearch -m user_avc,avc,selinux_err -ts 19:35 -i | grep sys_module | audit2why
> type=AVC msg=audit(10/25/2013 19:35:43.392:140) : avc:  denied  { sys_module } for  pid=494 comm=modprobe capability=sys_module  scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=capability 
> 
>         Was caused by:
>         The boolean secure_mode_policyload was set incorrectly. 
>         Description:
>         Allow secure to mode policyload
> 
>         Allow access by executing:
>         # setsebool -P secure_mode_policyload 1




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[James Carter]

On 10/25/2013 01:53 PM, Dominick Grift wrote:
> On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
>> I pushed an update of CIL to bitbucket.
>
> Is it me or is the negator "not" not working here:
>
>> (boolean secure_mode_insmod false)
>
>> (booleanif (not secure_mode_insmod)
>>    (true
>>      (allow loadkernelmodule self (capability (sys_module sys_nice)))
>>      (allow loadkernelmodule kernel_t (process (setsched)))))
>>
>
>
>> (macro kernel_load_module ((type ARG1))
>>    (typeattributeset loadkernelmodule ARG1))
>
>> (call kernel_load_module (kernel_t))
>
>> # getsebool -a | grep insmod
>> secure_mode_insmod --> off
>
>
>> # sesearch -ASCT -p sys_module | grep insmod
>> ET allow kernel_t kernel_t : capability { sys_module sys_nice } ; [ secure_mode_insmod ! ]
>

This looks correct and the branch is enabled. I don't know why it is not 
working. I will take a look.

>> # ausearch -m user_avc,avc,selinux_err -ts 19:35 -i | grep sys_module | audit2why
>> type=AVC msg=audit(10/25/2013 19:35:43.392:140) : avc:  denied  { sys_module } for  pid=494 comm=modprobe capability=sys_module  scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=capability
>>
>>          Was caused by:
>>          The boolean secure_mode_policyload was set incorrectly.
>>          Description:
>>          Allow secure to mode policyload
>>
>>          Allow access by executing:
>>          # setsebool -P secure_mode_policyload 1
>
>


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> I pushed an update of CIL to bitbucket.

Here is one last weird thing i am facing before the weekend:


> [root@localhost support]# ausearch -m avc,user_avc,selinux_err -ts 20:37
> <no matches>
> [root@localhost support]# seinfo -xcdbus
>    dbus
>       acquire_svc
>       send_msg
> [root@localhost support]# sesearch -A -s systemd_t -t systemd_t | grep dbus
>    allow dbusunconfined domaintype : dbus { acquire_svc send_msg } ; 
> [root@localhost support]# load_policy
> [root@localhost support]# ausearch -m avc,user_avc,selinux_err -ts 20:37 | grep dbus
> type=USER_AVC msg=audit(1382726311.163:635): pid=478 uid=81 auid=4294967295 ses=4294967295  subj=system_u:system_r:systemd_t:s0 msg='avc:  denied  { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=AddMatch dest=org.freedesktop.DBus spid=530 scontext=system_u:system_r:systemd_t:s0 tcontext=system_u:system_r:systemd_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-25 at 14:40 -0400, James Carter wrote:

> 
> This looks correct and the branch is enabled. I don't know why it is not 
> working. I will take a look.
> 
> >> # ausearch -m user_avc,avc,selinux_err -ts 19:35 -i | grep sys_module | audit2why
> >> type=AVC msg=audit(10/25/2013 19:35:43.392:140) : avc:  denied  { sys_module } for  pid=494 comm=modprobe capability=sys_module  scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=capability
> >>
> >>          Was caused by:
> >>          The boolean secure_mode_policyload was set incorrectly.
> >>          Description:
> >>          Allow secure to mode policyload
> >>
> >>          Allow access by executing:
> >>          # setsebool -P secure_mode_policyload 1

By the way look at that audit2why output, its talking about a whole
different boolean there since its not secure_mode_policyload, but rather
secure_mode_insmod...

The point is that i am getting this avc denial at boot, and audit2allow
say's it would have been allowed by current policy.

Almost just like my other dbus issue, very strange (showing avc denials
for things that are allowed in policy)


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> I pushed an update of CIL to bitbucket.

Some other things i noticed:

dontaudit seems to not work ( at least not in the scenario below ):

> (macro domtrans_pattern ((type ARG1) (type ARG2) (type ARG3))
>   (call domain_auto_transition_pattern (ARG1 ARG2 ARG3))
>   (allow ARG3 ARG1 (fd (use)))
>   (allow ARG3 ARG1 (rw_fifo_file_perms))
>   (allow ARG3 ARG1 (process (sigchld))))

> (macro domain_auto_transition_pattern ((type ARG1) (type ARG2) (type ARG3))
>   (call domain_transition_pattern (ARG1 ARG2 ARG3))
>   (typetransition ARG1 ARG2 process "*" ARG3))

> (macro domain_transition_pattern ((type ARG1) (type ARG2) (type ARG3))
>   (allow ARG1 ARG2 (mmap_file_perms))
>   (allow ARG1 ARG3 (process (transition)))
>   (dontaudit ARG1 ARG3 (process (noatsecure siginh rlimitinh))))

> (macro systemd_domtrans_cgroups_agent ((type ARG1))
>   (call domtrans_pattern (ARG1 systemd_cgroups_agent_exec_t
>             systemd_cgroups_agent_t)))

> (optional dependsonsystemd_kernel
> (call systemd_signal (kernel_t))
> (call systemd_sigchld (kernel_t))
> (call systemd_domtrans (kernel_t))
> (call domain_dyntrans_type (kernel_t))
> (call systemd_domtrans_cgroups_agent (kernel_t))
> (call systemd_dyntrans (kernel_t)))

> # sesearch --dontaudit -s kernel_t
> 

> allow kernel_t systemd_cgroups_agent_t:process { siginh rlimitinh noatsecure };
> 

I am also seeing a weird issue where some things are created with a wrong context

for example:

> # ls -alZ /dev/pts/ptmx
> c---------. root root system_u:system_r:kernel_t:s0    /dev/pts/ptmx

there is a type transition rule:

> (macro filesystem_devpts_filetrans ((type ARG1) (class ARG2) (name ARG3)
>             (type ARG4))
>   (call devices_list (ARG1))
>   (call filetrans_pattern (ARG1 devpts_t ARG2 ARG3 ARG4)))

> (macro filetrans_pattern ((type ARG1) (type ARG2) (class ARG3)
>             (name ARG4) (type ARG5))
>   (allow ARG1 ARG2 (rw_dir_perms))
>   (typetransition ARG1 ARG2 ARG3 ARG4 ARG5))

> (macro term_filetrans_ptmx ((type ARG1) (name ARG2))
> (call filesystem_devpts_filetrans (ARG1 chr_file ARG2 ptmx_t))
> (call devices_filetrans (ARG1 chr_file ARG2 ptmx_t)))

> (macro devices_filetrans ((type ARG1) (class ARG2) (name ARG3) (type ARG4))
>   (call filetrans_pattern (ARG1 device_t ARG2 ARG3 ARG4)))

> (call term_filetrans_ptmx (kernel_t "ptmx"))


> # sesearch -ASCT -s kernel_t | grep ptmx
>    allow kernel_t ptmx_t : chr_file { create getattr setattr open } ; 
> type_transition kernel_t device_t : chr_file ptmx_t "ptmx"; 
> type_transition kernel_t devpts_t : chr_file ptmx_t "ptmx";


By the way on a slight unrelated note:

In the filecon() we use symlink, char, block (etc) but elsewhere its lnk_file, chr_file, blk_file (etc)

I prefer consistency



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Update to CIL

[Dominick Grift]

On Fri, 2013-10-18 at 14:20 -0400, James Carter wrote:
> I pushed an update of CIL to bitbucket.

Here is another way to make secilc segfault:

> (typeattribute canrelabeltoshadow)
> 
> (typeattribute authunconfined)

> ; Never allow relabelto operation on shadow_t files unless the source
> ; is associated with canrelabeltoshadow or authunconfined
> 
> (typeattribute notcanrelabeltoshadoworauthunconfined)
> 
> (typeattributeset notcanrelabeltoshadoworauthunconfined
>             (not (or notcanrelabeltoshadoworauthunconfined authunconfined)))
> 
> (neverallow notcanrelabeltoshadoworauthunconfined shadow_t (file
>             (relabelto)))
> 

Its obviously a bug in the policy, but nonetheless it is like you said earlier: secilc should not segfault




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.