Re: audit rule problem

[Steve Grubb <sgrubb@redhat.com>]

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