Excluding certain processes

Excluding certain processes

[rshaw1]

I'm running audit 1.7.17-3 (RHEL 5) on ~450 clients sending via audisp to
a single server.  This is mostly working well, except that periodically, I
get messages like:

Jan  4 07:57:33 hostfoo audispd: queue is full - dropping event
Jan  4 07:58:04 hostfoo last message repeated 814 times
Jan  4 07:59:05 hostfoo last message repeated 4121 times
Jan  4 08:00:06 hostfoo last message repeated 2602 times
Jan  4 08:00:31 hostfoo last message repeated 773 times

Reading through the man pages, I've increased the q_depth value in
audispd.conf.  But even with it set at 99999 (the maximum), many events
are still being dropped from almost half the clients.  Setting disp_qos to
"lossless" in auditd.conf has also not helped.

It would be nice to solve this in general.  More specifically, however, I
know that on the worst offender, the flood of events is being caused by an
rsync job that runs at 8 and 12.  The events look something like:

node=hostfoo.domain.com type=SYSCALL msg=audit(1294232521.544:29609884):
arch=c000003e syscall=90 success=yes exit=0 a0=7fffbe5a7f60 a1=1ed a2=1
a3=0 items=1 ppid=4397 pid=4398 auid=4990 uid=4990 gid=100 euid=4990
suid=4990 fsuid=4990 egid=100 sgid=100 fsgid=100 tty=(none) ses=2867
comm="rsync" exe="/home/bob/.toast/pkg/rsync/v3.0.4/1/root/bin/rsync"
key="perm_mod"

Is there any way I can tell the perm_mod rules in audit.rules "Don't tell
me about it if the command is rsync"?  I couldn't find an obvious answer
from the auditctl man page (it doesn't seem that I can just specify, say,
comm!=rsync).

Thanks,

--Ray

Re: Excluding certain processes

[LC Bruzenak]

On Wed, 2011-01-05 at 08:35 -0500, rshaw1@umbc.edu wrote: 
> I'm running audit 1.7.17-3 (RHEL 5) on ~450 clients sending via audisp to
> a single server.  This is mostly working well, except that periodically, I
> get messages like:
> 
> Jan  4 07:57:33 hostfoo audispd: queue is full - dropping event
> Jan  4 07:58:04 hostfoo last message repeated 814 times
> Jan  4 07:59:05 hostfoo last message repeated 4121 times
> Jan  4 08:00:06 hostfoo last message repeated 2602 times
> Jan  4 08:00:31 hostfoo last message repeated 773 times
> 
> Reading through the man pages, I've increased the q_depth value in
> audispd.conf.  But even with it set at 99999 (the maximum), many events
> are still being dropped from almost half the clients.  Setting disp_qos to
> "lossless" in auditd.conf has also not helped.
> 
> It would be nice to solve this in general.  More specifically, however, I
> know that on the worst offender, the flood of events is being caused by an
> rsync job that runs at 8 and 12.  The events look something like:
> 
> node=hostfoo.domain.com type=SYSCALL msg=audit(1294232521.544:29609884):
> arch=c000003e syscall=90 success=yes exit=0 a0=7fffbe5a7f60 a1=1ed a2=1
> a3=0 items=1 ppid=4397 pid=4398 auid=4990 uid=4990 gid=100 euid=4990
> suid=4990 fsuid=4990 egid=100 sgid=100 fsgid=100 tty=(none) ses=2867
> comm="rsync" exe="/home/bob/.toast/pkg/rsync/v3.0.4/1/root/bin/rsync"
> key="perm_mod"
> 
> Is there any way I can tell the perm_mod rules in audit.rules "Don't tell
> me about it if the command is rsync"?  I couldn't find an obvious answer
> from the auditctl man page (it doesn't seem that I can just specify, say,
> comm!=rsync).
> 
> Thanks,
> 
> --Ray

Ray,

I think your example illustrates why you would not want to filter based
on command name since it is a non-standard rsync
(/home/bob/.toast/pkg/rsync/v3.0.4/1/root/bin/rsync).
Probably a trojan. :)

The problem is that you likely do not want to disallow all rsync events,
just the ones you want to allow to run event-free. 

Otherwise you are effectively overriding the rule which specifies these
events in the first place, since everyone can run rsync  - or maybe it
justifies removing this rule in your case?

You can do it by controlling access to rsync, then disallow selected
subjects, with types (custom policy) or group (egid). Or set a range of
UIDs which are allowed to rsync free of audit, then specify that range
of UIDs as acceptable in your rule.

You are right; rsyncs generate LOTS of events due to this rule and
basically can overflow the event queue regardless of the settings.

The easiest way (just a theory), if this is a cron job, is to run it as
a particular pseudo-user from /etc/cron.d/, then add that uid to the
rule with "-F euid!= 1000". You could add that pseudo user ID to the
sudoers file and have it run rsync with nopasswd.

Bottom line is that there are a few ways around it but nothing as simple
as excluding by command.

HTH,
LCB

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

Re: Excluding certain processes

[Steve Grubb]

On Wednesday, January 05, 2011 02:27:58 pm LC Bruzenak wrote:
> On Wed, 2011-01-05 at 08:35 -0500, rshaw1@umbc.edu wrote:
> > I'm running audit 1.7.17-3 (RHEL 5) on ~450 clients sending via audisp to
> > a single server.  This is mostly working well, except that periodically,
> > I get messages like:
> > 
> > Jan  4 07:57:33 hostfoo audispd: queue is full - dropping event
> > Jan  4 07:58:04 hostfoo last message repeated 814 times
> > Jan  4 07:59:05 hostfoo last message repeated 4121 times
> > Jan  4 08:00:06 hostfoo last message repeated 2602 times
> > Jan  4 08:00:31 hostfoo last message repeated 773 times
> > 
> > Reading through the man pages, I've increased the q_depth value in
> > audispd.conf.  But even with it set at 99999 (the maximum), many events
> > are still being dropped from almost half the clients.  Setting disp_qos
> > to "lossless" in auditd.conf has also not helped.
> > 
> > It would be nice to solve this in general.  More specifically, however, I
> > know that on the worst offender, the flood of events is being caused by
> > an rsync job that runs at 8 and 12.  The events look something like:
> > 
> > node=hostfoo.domain.com type=SYSCALL msg=audit(1294232521.544:29609884):
> > arch=c000003e syscall=90 success=yes exit=0 a0=7fffbe5a7f60 a1=1ed a2=1
> > a3=0 items=1 ppid=4397 pid=4398 auid=4990 uid=4990 gid=100 euid=4990
> > suid=4990 fsuid=4990 egid=100 sgid=100 fsgid=100 tty=(none) ses=2867
> > comm="rsync" exe="/home/bob/.toast/pkg/rsync/v3.0.4/1/root/bin/rsync"
> > key="perm_mod"
> > 
> > Is there any way I can tell the perm_mod rules in audit.rules "Don't tell
> > me about it if the command is rsync"?  I couldn't find an obvious answer
> > from the auditctl man page (it doesn't seem that I can just specify, say,
> > comm!=rsync).
> > 
> > Thanks,
> > 
> > --Ray
> 
> Ray,
> 
> I think your example illustrates why you would not want to filter based
> on command name since it is a non-standard rsync
> (/home/bob/.toast/pkg/rsync/v3.0.4/1/root/bin/rsync).
> Probably a trojan. :)
> 
> The problem is that you likely do not want to disallow all rsync events,
> just the ones you want to allow to run event-free.
> 
> Otherwise you are effectively overriding the rule which specifies these
> events in the first place, since everyone can run rsync  - or maybe it
> justifies removing this rule in your case?
> 
> You can do it by controlling access to rsync, then disallow selected
> subjects, with types (custom policy) or group (egid). Or set a range of
> UIDs which are allowed to rsync free of audit, then specify that range
> of UIDs as acceptable in your rule.
>
> You are right; rsyncs generate LOTS of events due to this rule and
> basically can overflow the event queue regardless of the settings.
> 
> The easiest way (just a theory), if this is a cron job, is to run it as
> a particular pseudo-user from /etc/cron.d/, then add that uid to the
> rule with "-F euid!= 1000". You could add that pseudo user ID to the
> sudoers file and have it run rsync with nopasswd.

Yeah a custom uid might help your situation. Also look at boosting the priority so 
that audispd gets more runtime.

-Steve

> Bottom line is that there are a few ways around it but nothing as simple
> as excluding by command.
> 
> HTH,
> LCB