On Wed, 2011-01-05 at 08:35 -0500, rshaw1(a)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