auditctl se_sen & se_clr

auditctl se_sen & se_clr

[Michael C Thompson]

Hey all,

I'm trying to figure out how the se_sen and se_clr labels are supposed 
to be used with auditctl.

Here is the selinux context:
subj=root:staff_r:staff_t:s0-s15:c0.c255
       ^      ^       ^        ^
    se_user   ^    se_type     ^
            se_role          se_clr & se_sen

What is the difference between se_clr and se_sen? And if you have any 
enlightening examples, that would be appreciated.

Thanks,
Mike

Re: auditctl se_sen & se_clr

[Stephen Smalley]

On Fri, 2006-05-19 at 10:07 -0500, Michael C Thompson wrote:
> Hey all,
> 
> I'm trying to figure out how the se_sen and se_clr labels are supposed 
> to be used with auditctl.
> 
> Here is the selinux context:
> subj=root:staff_r:staff_t:s0-s15:c0.c255
>        ^      ^       ^        ^
>     se_user   ^    se_type     ^
>             se_role          se_clr & se_sen
> 
> What is the difference between se_clr and se_sen? And if you have any 
> enlightening examples, that would be appreciated.

IIRC, se_sen is how audit refers to the low level (aka sensitivity,
current level) and se_clr is how audit refers to the high level (aka
clearance, max level) of a MLS range in a SELinux context.  In the
context above, the se_sen would be the "s0" and the se_clr would be the
"s15:c0.c255".

-- 
Stephen Smalley
National Security Agency

Re: auditctl se_sen & se_clr

[Michael C Thompson]

Stephen Smalley wrote:
> On Fri, 2006-05-19 at 10:07 -0500, Michael C Thompson wrote:
>> Hey all,
>>
>> I'm trying to figure out how the se_sen and se_clr labels are supposed 
>> to be used with auditctl.
>>
>> Here is the selinux context:
>> subj=root:staff_r:staff_t:s0-s15:c0.c255
>>        ^      ^       ^        ^
>>     se_user   ^    se_type     ^
>>             se_role          se_clr & se_sen
>>
>> What is the difference between se_clr and se_sen? And if you have any 
>> enlightening examples, that would be appreciated.
> 
> IIRC, se_sen is how audit refers to the low level (aka sensitivity,
> current level) and se_clr is how audit refers to the high level (aka
> clearance, max level) of a MLS range in a SELinux context.  In the
> context above, the se_sen would be the "s0" and the se_clr would be the
> "s15:c0.c255".

Thanks, that's what I thought as well. Here is my result of testing this:

root linux user, id:
uid=0(root) gid=0(root) 
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) 
context=root:staff_r:staff_t:SystemLow-SystemHigh

mcthomps linux user, id:
uid=500(mcthomps) gid=500(mcthomps) groups=500(mcthomps) 
context=user_u:user_r:user_t:SystemLow

When I have the following audit rule is
   auditctl -a entry,always -S chmod -F se_clr=s0
the chmod actions taken by mcthomps get logged, but not those done by 
root (this is as expected).

When the audit rule is
   auditctl -a entry,always -S chmod -F se_clr=s15:c0.c255
the chmod actions taken by root get logged, but not by mcthomps (also 
expected).

However, for se_sen, this does not seem to be the case. The rule:
   auditctl -a entry,always -S chmod -F se_se=s0
should cause chmod actions taken by both mcthomps and root to be logged, 
right? However, I'm only seeing the result of actions taken by mcthomps.

I've also tried to see if se_sen was the entire context, but that 
doesn't seem to be the case...

Any ideas? If someone else could take a crack at testing this too, I'd 
like to make sure its not just me :)

Thanks,
Mike

Re: auditctl se_sen & se_clr

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 1345 bytes --]

On Fri, 2006-05-19 at 10:30 -0500, Michael C Thompson wrote:

> Thanks, that's what I thought as well. Here is my result of testing this:
> 
> root linux user, id:
> uid=0(root) gid=0(root) 
> groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) 
> context=root:staff_r:staff_t:SystemLow-SystemHigh
> 
> mcthomps linux user, id:
> uid=500(mcthomps) gid=500(mcthomps) groups=500(mcthomps) 
> context=user_u:user_r:user_t:SystemLow
> 
> When I have the following audit rule is
>    auditctl -a entry,always -S chmod -F se_clr=s0
> the chmod actions taken by mcthomps get logged, but not those done by 
> root (this is as expected).


 This means that a "range" of s0 is being interpreted as:

se_sen=''
se_clr='s0'

...which isn't what I'd expect, but given that...

> When the audit rule is
>    auditctl -a entry,always -S chmod -F se_clr=s15:c0.c255
> the chmod actions taken by root get logged, but not by mcthomps (also 
> expected).
> 
> However, for se_sen, this does not seem to be the case. The rule:
>    auditctl -a entry,always -S chmod -F se_se=s0
> should cause chmod actions taken by both mcthomps and root to be logged, 
> right? However, I'm only seeing the result of actions taken by mcthomps.

 This follows the same methodology.

-- 
James Antill
<james.antill@redhat.com>


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: auditctl se_sen & se_clr

[Michael C Thompson]

James Antill wrote:
> On Fri, 2006-05-19 at 10:30 -0500, Michael C Thompson wrote:
> 
>> Thanks, that's what I thought as well. Here is my result of testing this:
>>
>> root linux user, id:
>> uid=0(root) gid=0(root) 
>> groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) 
>> context=root:staff_r:staff_t:SystemLow-SystemHigh
>>
>> mcthomps linux user, id:
>> uid=500(mcthomps) gid=500(mcthomps) groups=500(mcthomps) 
>> context=user_u:user_r:user_t:SystemLow
>>
>> When I have the following audit rule is
>>    auditctl -a entry,always -S chmod -F se_clr=s0
>> the chmod actions taken by mcthomps get logged, but not those done by 
>> root (this is as expected).
> 
> 
>  This means that a "range" of s0 is being interpreted as:
> 
> se_sen=''
> se_clr='s0'
> 
> ...which isn't what I'd expect, but given that...

I'm sorry, I do not follow what you mean here.

>> When the audit rule is
>>    auditctl -a entry,always -S chmod -F se_clr=s15:c0.c255
>> the chmod actions taken by root get logged, but not by mcthomps (also 
>> expected).
>>
>> However, for se_sen, this does not seem to be the case. The rule:
>>    auditctl -a entry,always -S chmod -F se_se=s0
>> should cause chmod actions taken by both mcthomps and root to be logged, 
>> right? However, I'm only seeing the result of actions taken by mcthomps.
> 
>  This follows the same methodology.

again, I'm confused as to what you mean.

Thanks,
Mike

Re: auditctl se_sen & se_clr

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 1169 bytes --]

On Fri, 2006-05-19 at 12:44 -0500, Michael C Thompson wrote:
> James Antill wrote:
> > On Fri, 2006-05-19 at 10:30 -0500, Michael C Thompson wrote:
> > 
> >> Thanks, that's what I thought as well. Here is my result of testing this:
> >>
> >> root linux user, id:
> >> context=root:staff_r:staff_t:SystemLow-SystemHigh
> >>
> >> mcthomps linux user, id:
> >> context=user_u:user_r:user_t:SystemLow
> >>
> >> When I have the following audit rule is
> >>    auditctl -a entry,always -S chmod -F se_clr=s0
> >> the chmod actions taken by mcthomps get logged, but not those done by 
> >> root (this is as expected).
> > 
> >  This means that a "range" of s0 is being interpreted as:
> > 
> > se_sen=''
> > se_clr='s0'
> > 
> > ...which isn't what I'd expect, but given that...
> 
> I'm sorry, I do not follow what you mean here.

 The mls range for root is s0-s0:c0.c255, where:

 se_sen = s0
 se_clr = s0:c0.c255

 The mls range for mcthomps is s0, given the above works then:

 se_clr = s0

...and given the range is s0 and not s0-s0 then se_sen must be blank
(and so won't match s0).

-- 
James Antill
<james.antill@redhat.com>


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: auditctl se_sen & se_clr

[Michael C Thompson]

James Antill wrote:
> On Fri, 2006-05-19 at 12:44 -0500, Michael C Thompson wrote:
>> James Antill wrote:
>>> On Fri, 2006-05-19 at 10:30 -0500, Michael C Thompson wrote:
>>>
>>>> Thanks, that's what I thought as well. Here is my result of testing this:
>>>>
>>>> root linux user, id:
>>>> context=root:staff_r:staff_t:SystemLow-SystemHigh
>>>>
>>>> mcthomps linux user, id:
>>>> context=user_u:user_r:user_t:SystemLow
>>>>
>>>> When I have the following audit rule is
>>>>    auditctl -a entry,always -S chmod -F se_clr=s0
>>>> the chmod actions taken by mcthomps get logged, but not those done by 
>>>> root (this is as expected).
>>>  This means that a "range" of s0 is being interpreted as:
>>>
>>> se_sen=''
>>> se_clr='s0'
>>>
>>> ...which isn't what I'd expect, but given that...
>> I'm sorry, I do not follow what you mean here.
> 
>  The mls range for root is s0-s0:c0.c255, where:
> 
>  se_sen = s0
>  se_clr = s0:c0.c255

Right, this makes sense.

>  The mls range for mcthomps is s0, given the above works then:
> 
>  se_clr = s0
> 
> ...and given the range is s0 and not s0-s0 then se_sen must be blank
> (and so won't match s0).


AFIAK, you must have both a low and a high, which means for mcthomps, 
se_sen=0 and se_clr=s0.

The testing that I have done with auditctl's se_sen and se_clr filters 
has the se_clr working for both the root user and the mcthomps user, but 
  se_sen only captures audit events for mcthomps when:
auditctl -a entry,always -S chmod -F se_sen=s0

I would expect that since se_sen=s0 for both root and mcthomps, that 
both of their chmod actions would be logged, but root's actions are not 
being captured.

This leads me to believe either our definition of se_sen is wrong, or if 
our definition of se_sen is correct, then the implementation of se_sen 
has some bug in it.

Thanks,
Mike

Re: auditctl se_sen & se_clr

[Steve Grubb]

On Friday 19 May 2006 15:30, Michael C Thompson wrote:
> This leads me to believe either our definition of se_sen is wrong, or if
> our definition of se_sen is correct, then the implementation of se_sen
> has some bug in it.

You may need to take this discussion to the LSPP mail list where more SE Linux 
folks are watching. Darryl and Dustin did that work. Might be good to ask 
Darryl about this.

-Steve

[PATCH] fix se_sen audit filter

[Darrel Goeddel]

Michael C Thompson wrote:
> James Antill wrote:
> 
>> On Fri, 2006-05-19 at 12:44 -0500, Michael C Thompson wrote:
>>
>>> James Antill wrote:
>>>
>>>> On Fri, 2006-05-19 at 10:30 -0500, Michael C Thompson wrote:
>>>>
>>>>> Thanks, that's what I thought as well. Here is my result of testing 
>>>>> this:
>>>>>
>>>>> root linux user, id:
>>>>> context=root:staff_r:staff_t:SystemLow-SystemHigh
>>>>>
>>>>> mcthomps linux user, id:
>>>>> context=user_u:user_r:user_t:SystemLow
>>>>>
>>>>> When I have the following audit rule is
>>>>>    auditctl -a entry,always -S chmod -F se_clr=s0
>>>>> the chmod actions taken by mcthomps get logged, but not those done 
>>>>> by root (this is as expected).
>>>>
>>>>  This means that a "range" of s0 is being interpreted as:
>>>>
>>>> se_sen=''
>>>> se_clr='s0'
>>>>
>>>> ...which isn't what I'd expect, but given that...
>>>
>>> I'm sorry, I do not follow what you mean here.
>>
>>
>>  The mls range for root is s0-s0:c0.c255, where:
>>
>>  se_sen = s0
>>  se_clr = s0:c0.c255
> 
> 
> Right, this makes sense.
> 
>>  The mls range for mcthomps is s0, given the above works then:
>>
>>  se_clr = s0
>>
>> ...and given the range is s0 and not s0-s0 then se_sen must be blank
>> (and so won't match s0).
> 
> 
> 
> AFIAK, you must have both a low and a high, which means for mcthomps, 
> se_sen=0 and se_clr=s0.
> 
> The testing that I have done with auditctl's se_sen and se_clr filters 
> has the se_clr working for both the root user and the mcthomps user, but 
>  se_sen only captures audit events for mcthomps when:
> auditctl -a entry,always -S chmod -F se_sen=s0
> 
> I would expect that since se_sen=s0 for both root and mcthomps, that 
> both of their chmod actions would be logged, but root's actions are not 
> being captured.
> 
> This leads me to believe either our definition of se_sen is wrong, or if 
> our definition of se_sen is correct, then the implementation of se_sen 
> has some bug in it.

Bug seems to be the way to go here.  Below is a patch that fixes it.




Fix a broken comparison that causes the process clearance to be checked for
both se_clr and se_sen audit filters.

Signed-off-by: Darrel Goeddel <dgoeddel@trustedcs.com>

--

diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index c284dbb..e9548bc 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1980,7 +1980,7 @@ int selinux_audit_rule_match(u32 ctxid,
                break;
        case AUDIT_SE_SEN:
        case AUDIT_SE_CLR:
-               level = (op == AUDIT_SE_SEN ?
+               level = (field == AUDIT_SE_SEN ?
                         &ctxt->range.level[0] : &ctxt->range.level[1]);
                switch (op) {
                case AUDIT_EQUAL:

-- 

Darrel

Re: auditctl se_sen & se_clr

[Michael C Thompson]

Michael C Thompson wrote:
> Hey all,
> 
> I'm trying to figure out how the se_sen and se_clr labels are supposed 
> to be used with auditctl.
> 
> Here is the selinux context:
> subj=root:staff_r:staff_t:s0-s15:c0.c255
>       ^      ^       ^        ^
>    se_user   ^    se_type     ^
>            se_role          se_clr & se_sen
> 
> What is the difference between se_clr and se_sen? And if you have any 
> enlightening examples, that would be appreciated.

This is no longer an issue, it has been resolved since .28 kernel and 
audit-1.2.3.

Thanks,
Mike