Be careful with rules

[Lenny Bruzenak]

All,

I came across some strange behavior recently on SElinux with audit 
rules. It has been in the kernel a long time. I thought it was worth 
sharing.

If you specify a non-existent type in a audit syscall filter rule, the 
kernel will accept it and advertise it as being valid, but in essence it 
invalidates all audits of those syscalls.

For example, starting with this common rule:

# auditctl -a exit,always -F arch=b64 -S mount,umount2 -k MNT

# auditctl -l -k MNT

-a always,exit -F arch=b64 -S mount,umount2 -F key=MNT


All good. Try mounting and unmounting, you'll get audited results with:

# ausearch -i -k MNT


Now, delete that rule (assuming you didn't already have the rules loaded 
with the "-e 2"  which locks the rules),

# auditctl -d exit,always -F arch=b64 -S mount,umount2 -k MNT

and you will not see any more mount/umount syscall events. Fine.


But, change the rule to use a non-existent type value, such as:

# auditctl -a exit,always -F arch=b64 -S mount,umount2 -F 
subj_type!=e_snowden_t -k MNT

and the return code is valid, plus it appears all is well:

# auditctl -l -k MNT

-a always,exit -F arch=b64 -S mount,umount2-F subj_type!=e_snowden_t -F 
key=MNT


So, being the naive user that I am, I assume that this rule is in 
effect, valid, and means, "Audit all mount/umount2 syscalls except those 
of subject type e_snowden_t and mark them with the MNT key".

But that isn't what happens.

Instead, what happens is that:

 1. A message gets written into the dmesg buffer saying "[<timestamp>]
    audit rule for LSM 'e_snowden_t' is invalid".
 2. All subsequent mount/umount syscalls are now NOT audited, regardless
    of the types. There is essentially no mount/umount2 rule valid at
    this point, regardless of the "auditctl -l" answer.


I verified that in the current github code this is accurate for (1) 
above, then asked about it:

https://github.com/linux-audit/audit-kernel/blame/69bb189e81e081a4e92e8fa4cbcc9fd407252dc1/kernel/auditfilter.c#L531-L538


I've been told that it is not a potential security problem, and not 
subject to change in the (current) kernel.

I'm hoping that it may help someone else in being aware that:

  * You cannot trust what the kernel says WRT audit rules that specify
    type, and therefore
  * You need to be certain that you do not field a system having audit
    rules with a non-existent value in the field specifiers that deal
    with subject or object values.


Thx,

LCB


-- 
Lenny Bruzenak
MagitekLTD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20220606/def0584e/attachment.htm>