public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
* Filtering audit events
@ 2015-08-31 12:18 rshaw1
  2015-08-31 13:22 ` Steven Grubb
  0 siblings, 1 reply; 4+ messages in thread
From: rshaw1 @ 2015-08-31 12:18 UTC (permalink / raw)
  To: linux-audit

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Filtering audit events
  2015-08-31 12:18 Filtering audit events rshaw1
@ 2015-08-31 13:22 ` Steven Grubb
  2015-08-31 13:58   ` rshaw1
  0 siblings, 1 reply; 4+ messages in thread
From: Steven Grubb @ 2015-08-31 13:22 UTC (permalink / raw)
  To: rshaw1; +Cc: linux-audit



----- Original Message -----
>From: rshaw1@umbc.edu
>To: linux-audit@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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Filtering audit events
  2015-08-31 13:22 ` Steven Grubb
@ 2015-08-31 13:58   ` rshaw1
  2015-09-02 23:31     ` Steve Grubb
  0 siblings, 1 reply; 4+ messages in thread
From: rshaw1 @ 2015-08-31 13:58 UTC (permalink / raw)
  To: linux-audit


> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Filtering audit events
  2015-08-31 13:58   ` rshaw1
@ 2015-09-02 23:31     ` Steve Grubb
  0 siblings, 0 replies; 4+ messages in thread
From: Steve Grubb @ 2015-09-02 23:31 UTC (permalink / raw)
  To: linux-audit

On Monday, August 31, 2015 09:58:42 AM rshaw1@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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-09-02 23:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-31 12:18 Filtering audit events rshaw1
2015-08-31 13:22 ` Steven Grubb
2015-08-31 13:58   ` rshaw1
2015-09-02 23:31     ` Steve Grubb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox