Discussion:
audit rule problem
(too old to reply)
LC Bruzenak
2017-11-15 00:38:48 UTC
Permalink
Raw Message
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.?.

However, the bigger problem is that trying to add my other valid custom
types into the exclusion on the mls policy machine is causing me to lose
events. Any ideas?

Thx,
LCB
--
LC (Lenny) Bruzenak
***@magitekltd.com
LC Bruzenak
2017-11-15 17:06:31 UTC
Permalink
Raw Message
Post by LC Bruzenak
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)
-a exit,always -F arch=b64 -S mount -S umount2 -k mount
-a exit,always -F arch=b64 -S mount -S umount2 -F
subj_type!=nothing_t -k mount
# 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...

Thx,
LCB
--
LC (Lenny) Bruzenak
***@magitekltd.com
Steve Grubb
2017-11-15 17:16:33 UTC
Permalink
Raw Message
Post by LC Bruzenak
Post by LC Bruzenak
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)
-a exit,always -F arch=b64 -S mount -S umount2 -k mount
-a exit,always -F arch=b64 -S mount -S umount2 -F
subj_type!=nothing_t -k mount
# 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.

[***@x2 ~]# auditctl -a always,exit -F arch=b64 -S open -F subj_type=doesnt_exist_t
[***@x2 ~]# echo $?
0
[***@x2 ~]# auditctl -l | grep doesnt_exist_t
-a always,exit -F arch=b64 -S open -F subj_type=doesnt_exist_t
[***@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
LC Bruzenak
2017-11-15 17:20:57 UTC
Permalink
Raw Message
Post by Steve Grubb
OK. That's something that can be checked. And I confirm this is the case.
0
-a 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
Thanks Steve. I wouldn't mind as much if it accepts types not currently
loaded (seems like a warning would be nice though), however the part
about it subsequently discarding valid events due to the bogus type is
the troubling part.

LCB
--
LC (Lenny) Bruzenak
***@magitekltd.com
Loading...