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:


Thx,

LCB


-- 
Lenny Bruzenak
MagitekLTD