Audit rule problem

Audit rule problem

[Roger Holm]

[-- Attachment #1.1: Type: text/plain, Size: 389 bytes --]

Hello.

 

I wonder if someone can help me with an audit rule issue? 

 

I want to log if someone uses the rpm command (to install/upgrade
packages), but not the rest of commands. Only the rpm command! 

Is it possible? If so, can anyone please tell me how to write the rule
string? I've searched the internet, without success.

 

 

Regards

 

Roger Holm

 


[-- Attachment #1.2: Type: text/html, Size: 2990 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audit rule problem

[Steve Grubb]

On Tuesday 17 July 2007 10:05:12 Roger Holm wrote:
> I want to log if someone uses the rpm command (to install/upgrade
> packages), but not the rest of commands. Only the rpm command!

Sure:

-w /bin/rpm -p x -k rpm-is-running

I added the key to make searching for the results easier. It also helps you 
know why the audit record was logged.

-Steve

Re: Audit rule problem

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 325 bytes --]

On Tue, 17 Jul 2007 16:05:12 +0200, Roger Holm said:

> I want to log if someone uses the rpm command (to install/upgrade
> packages), but not the rest of commands. Only the rpm command!

What do you want it to do if they use 'yum' instead of 'rpm', or
'cp /bin/rpm /bin/innocent; /bin/innocent -Uvh evil-0.99.3.noarch.rpm'?

[-- Attachment #1.2: Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

audit rule problem

[LC Bruzenak]

[-- Attachment #1.1: Type: text/plain, Size: 1082 bytes --]

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
lenny@magitekltd.com



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3805 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: audit rule problem

[LC Bruzenak]

[-- Attachment #1.1: Type: text/plain, Size: 1254 bytes --]

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...

Thx,
LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3805 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: audit rule problem

[Steve Grubb]

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

Re: audit rule problem

[LC Bruzenak]

[-- Attachment #1.1: Type: text/plain, Size: 1102 bytes --]

On 11/15/2017 10:16 AM, Steve Grubb wrote:
> 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

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
lenny@magitekltd.com



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3805 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]