auditctl se_sen & se_clr
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
Quoted 5 lines · Michael C Thompson
Hey all,
I'm trying to figure out how the
se_senandse_clrlabels are supposed to be used with auditctl.
Quoted 8 lines
Here is the selinux context:
subj=root:staff_r:staff_t:s0-s15:c0.c255^ ^ ^ ^ se_user ^ se_type ^
se_rolese_clr&se_senWhat is the difference between
se_clrandse_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".
Signature · 2 lines
Stephen Smalley National Security Agency
Quoted 11 lines · Stephen Smalley
Quoted 10 lines · Michael C Thompson
Hey all,
I'm trying to figure out how the
se_senandse_clrlabels 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_rolese_clr&se_sen
Quoted 7 lines
Quoted 1 line
What is the difference between
se_clrandse_sen? And if you have any enlightening examples, that would be appreciated.IIRC,
se_senis how audit refers to the low level (aka sensitivity, current level) andse_clris how audit refers to the high level (aka clearance, max level) of a MLS range in a SELinux context. In the context above, these_senwould be the "s0" and these_clrwould 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
Quoted 7 lines · Michael C Thompson
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
Quoted 8 lines
mcthomps linux user, id:
uid=500(mcthomps) gid=500(mcthomps) groups=500(mcthomps) context=user_u:user_r:user_t:SystemLowWhen 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...
Quoted 9 lines
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.
Signature · 2 lines
James Antill <[email protected]>
Quoted 15 lines · James Antill
Quoted 11 lines · Michael C Thompson
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-SystemHighmcthomps linux user, id:
uid=500(mcthomps) gid=500(mcthomps) groups=500(mcthomps) context=user_u:user_r:user_t:SystemLowWhen 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).
Quoted 6 lines
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.
Quoted 9 lines
Quoted 7 lines
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
Quoted 16 lines · Michael C Thompson
Quoted 15 lines · James Antill
Quoted 12 lines · Michael C Thompson
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-SystemHighmcthomps linux user, id:
context=user_u:user_r:user_t:SystemLowWhen 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).
Quoted 8 lines
Quoted 6 lines
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).
Signature · 2 lines
James Antill <[email protected]>
Quoted 20 lines · James Antill
Quoted 19 lines · Michael C Thompson
Quoted 18 lines · James Antill
Quoted 11 lines · Michael C Thompson
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-SystemHighmcthomps linux user, id:
context=user_u:user_r:user_t:SystemLowWhen 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'
Quoted 7 lines
Quoted 2 lines
Quoted 1 line
...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.
Quoted 6 lines
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_senmust 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
Quoted 3 lines · Michael C Thompson
This leads me to believe either our definition of
se_senis wrong, or if our definition ofse_senis correct, then the implementation ofse_senhas 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 1/1 fix se_sen audit filter
In reply to Michael C ThompsonQuoted 49 lines · Michael C Thompson
Quoted 25 lines · James Antill
Quoted 23 lines · Michael C Thompson
Quoted 20 lines · James Antill
Quoted 11 lines · Michael C Thompson
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-SystemHighmcthomps linux user, id:
context=user_u:user_r:user_t:SystemLowWhen 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...
Quoted 7 lines
Quoted 1 line
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.c255Right, this makes sense.
Quoted 6 lines
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_senmust 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.
Quoted 7 lines
The testing that I have done with auditctl's
se_senandse_clrfilters has these_clrworking for both the root user and the mcthomps user, but
se_senonly captures audit events for mcthomps when:
auditctl -a entry,always -S chmod -F se_sen=s0I 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_senis wrong, or if our definition ofse_senis correct, then the implementation ofse_senhas 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.
--
security/selinux/ss/services.c +1 -1
@@ -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 :
Signature · 1 line
Darrel
Quoted 11 lines · Michael C Thompson
Hey all,
I'm trying to figure out how the
se_senandse_clrlabels 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_rolese_clr&se_senWhat is the difference between
se_clrandse_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