On Wednesday, November 15, 2017 12:06:31 PM EST LC Bruzenak wrote:
On 11/14/2017 05:38 PM, LC Bruzenak wrote:
> System:
> Linux audit 2.6.32-696.3.2.el6.x86_64 #1 SMP Wed Jun 7 11:51:39 EDT
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> userspace audit-2.4.5-3
> Red Hat Enterprise Linux Client release 6.9 (Santiago)
>
> I changed this line in /etc/audit/audit.rules from:
> -a exit,always -F arch=b64 -S mount -S umount2 -k mount
> to this:
> -a exit,always -F arch=b64 -S mount -S umount2 -F
> subj_type!=nothing_t -k mount
>
> Reloaded my rules, and now doing (as root):
> # umount /boot; mount /boot
>
> no longer produces audit events. I did this because on another system
> (mls policy, with lots of custom types) I lost the events once I
> included some custom types installed and operational on the system, so
> I was just trying to reduce this to a reproducible case. I can almost
> see that a non-existent type might fail, but it maybe should fail to
> load.?.
Ugh.
Looks like the entire problem was a non-existent subject type; I had a
typo in the mls policy case.
So the rules accept a type which does not exist, does not warn, and then
fails to report all events.
That's my story and I'm sticking to it...
OK. That's something that can be checked. And I confirm this is the case.
[root@x2 ~]# auditctl -a always,exit -F arch=b64 -S open -F subj_type=doesnt_exist_t
[root@x2 ~]# echo $?
0
[root@x2 ~]# auditctl -l | grep doesnt_exist_t
-a always,exit -F arch=b64 -S open -F subj_type=doesnt_exist_t
[root@x2 ~]# auditctl -d always,exit -F arch=b64 -S open -F subj_type=doesnt_exist_t
That said, you can also write a rule with auid=40000 which would be an invalid
user. The kernel has no concept of what uids are valid. So, I expect we have
the same issue with policy. I don't know if the kernel can check if a type is
valid. Typically policy is compiled into numbers and that's what the kernel
understands.
-Steve