Be careful with rules

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/69bb189e81e081a4e92e8fa... 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