All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: Excluding certain processes
Date: Wed, 5 Jan 2011 15:45:55 -0500	[thread overview]
Message-ID: <201101051545.55825.sgrubb@redhat.com> (raw)
In-Reply-To: <1294255678.2040.149.camel@lcb>

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

      reply	other threads:[~2011-01-05 20:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 13:35 Excluding certain processes rshaw1
2011-01-05 19:27 ` LC Bruzenak
2011-01-05 20:45   ` Steve Grubb [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201101051545.55825.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.