7:18 a.m.
I'm trying to figure out a way to filter a large number of events similar
to the following:
time->Mon Aug 31 08:08:26 2015
type=PATH msg=audit(1441022906.019:52947542): item=1 name=(null) inode=133
dev=fd:06 mode=0100640 ouid=0 ogid=9002 rdev=00:00
obj=system_u:object_r:var_log_t:s0 nametype=NORMAL
type=PATH msg=audit(1441022906.019:52947542): item=0
name="/var/log/simpana/Log_Files/locks/" inode=92 dev=fd:06 mode=040775
ouid=0 ogid=9002 rdev=00:00 obj=system_u:object_r:var_log_t:s0
nametype=PARENT
type=CWD msg=audit(1441022906.019:52947542): cwd="/opt/simpana"
type=SYSCALL msg=audit(1441022906.019:52947542): arch=c000003e syscall=2
success=no exit=-13 a0=996d68 a1=42 a2=1b6 a3=0 items=2 ppid=11855
pid=15755 auid=7538 uid=0 gid=9002 euid=4990 suid=4990 fsuid=4990
egid=9002 sgid=9002 fsgid=9002 tty=(none) ses=125779 comm="clBackup"
exe="/opt/simpana/iDataAgent/clBackup" subj=system_u:system_r:initrc_t:s0
key="access"
The STIG-compliant audit ruleset we're using seems to generate a lot of
these, and I'm concerned that may be affecting the performance of the app
in question (also, I consider it log spam). I tried the following rule
(plus a few variations like ogid), but it doesn't seem to be working:
-a exit,never -F gid=9002 -k exclude
What would be the best way to approach this? I have a few other apps with
similar issues.
Thanks,
--Ray
8:22 a.m.
----- Original Message -----
From: rshaw1(a)umbc.edu
To: linux-audit(a)redhat.com
Sent: Monday, August 31, 2015 8:18:12 AM
Subject: Filtering audit events
I'm trying to figure out a way to filter a large number of events similar
to the following:
time->Mon Aug 31 08:08:26 2015
type=PATH msg=audit(1441022906.019:52947542): item=1 name=(null) inode=133
dev=fd:06 mode=0100640 ouid=0 ogid=9002 rdev=00:00
obj=system_u:object_r:var_log_t:s0 nametype=NORMAL
type=PATH msg=audit(1441022906.019:52947542): item=0
name="/var/log/simpana/Log_Files/locks/" inode=92 dev=fd:06 mode=040775
ouid=0 ogid=9002 rdev=00:00 obj=system_u:object_r:var_log_t:s0
nametype=PARENT
type=CWD msg=audit(1441022906.019:52947542): cwd="/opt/simpana"
type=SYSCALL msg=audit(1441022906.019:52947542): arch=c000003e syscall=2
success=no exit=-13 a0=996d68 a1=42 a2=1b6 a3=0 items=2 ppid=11855
pid=15755 auid=7538 uid=0 gid=9002 euid=4990 suid=4990 fsuid=4990
egid=9002 sgid=9002 fsgid=9002 tty=(none) ses=125779 comm="clBackup"
exe="/opt/simpana/iDataAgent/clBackup" subj=system_u:system_r:initrc_t:s0
key="access"
If you use the -i argument to ausearch, it becomes more clear what the issue is. The
problem is that the program is opening the file for read and write, but the permissions
are just for group read. If that file were 0660, then you would not get this audit event.
The STIG-compliant audit ruleset we're using seems to generate a
lot of
these, and I'm concerned that may be affecting the performance of the app
in question (also, I consider it log spam). I tried the following rule
(plus a few variations like ogid), but it doesn't seem to be working:
-a exit,never -F gid=9002 -k exclude
This should work as long as its before the open rule. Rules are processed from top to
bottom with first match winning.
What would be the best way to approach this?
Fix the permissions if possible?
-Steve
I have a few other apps with similar issues.
8:58 a.m.
If you use the -i argument to ausearch, it becomes more clear what
the
issue is. The problem is that the program is opening the file for read and
write, but the permissions are just for group read. If that file were
0660, then you would not get this audit event.
Hrm. The process is running as the root user, though. It's going over
the whole filesystem (for backups).
>The STIG-compliant audit ruleset we're using seems to generate
a lot of
>these, and I'm concerned that may be affecting the performance of the app
>in question (also, I consider it log spam). I tried the following rule
>(plus a few variations like ogid), but it doesn't seem to be working:
>
>-a exit,never -F gid=9002 -k exclude
This should work as long as its before the open rule. Rules are processed
from top to bottom with first match winning.
>What would be the best way to approach this?
It's pretty much at the top, well before the open rule. There are only
two other exclude rules before it, and the general settings:
-D
-b 8192
-f 1
This is on RHEL6, if that matters.
--Ray
6:31 p.m.
On Monday, August 31, 2015 09:58:42 AM rshaw1(a)umbc.edu wrote:
> If you use the -i argument to ausearch, it becomes more clear
what the
> issue is. The problem is that the program is opening the file for read and
> write, but the permissions are just for group read. If that file were
> 0660, then you would not get this audit event.
Hrm. The process is running as the root user, though. It's going over
the whole filesystem (for backups).
But look at all the uids it has:
auid=7538 uid=0 gid=9002 euid=4990 suid=4990 fsuid=4990
egid=9002 sgid=9002 fsgid=9002
I'm betting it;s a setuid program and is being prevented by various checks.
Its effective uid is 4990, its fsuid is 4990. If changing the permissions is
acceptable and fixes its, that what I'd do.
-Steve
3398
days inactive
3400
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
rshaw1＠umbc.edu -
Steve Grubb -
Steven Grubb