public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com, Andy Ruch <adruch2002@yahoo.com>
Subject: Re: Backlog exceeded when using audisp
Date: Fri, 15 Aug 2014 14:01:22 -0400	[thread overview]
Message-ID: <13673462.7keNk3W44N@x2> (raw)
In-Reply-To: <1408047139.57007.YahooMailNeo@web120702.mail.ne1.yahoo.com>

On Thursday, August 14, 2014 01:12:19 PM Andy Ruch wrote:
> Upon further testing, I think there might be something else as the root
> cause. For my testing, I'm adding an selinux user (semanage user -a ...).
> This will trigger a load_policy command for SELinux. When everything works
> fine, auditd processes roughly 2000 events and audisp handles this with no
> problems. However, sometimes when I run the command, auditd will receive
> over 15000 events. As far as I can tell, the extra events are all SELinux
> error events stating "selinux_audit_rule_match: stale rule". What would
> cause this 

Looking at kernel code, it would appear that you have rules that use selinux 
as part of the matching. When you load new policy, the sids (which is a number 
from the policy compiler) has likely changed and no longer matches what it 
thinks it does. The kernel only understands numbers. When you compile human 
readable selinux rules, it changes the text into numbers. If policy is 
changed, there is no guarantee that the number for say crond_t is the same as 
it used to be. So, the kernel detects that the audit rule mapping is using 
stale (old) sids.


> and why does it not happen every time? Is this an audit issue or
> an SELinux issue?

A little of both. A work around is probably to reload the audit rules 
immediately so that the sids get resolved against the new policy. The better 
fix would be to file a support ticket and ask for that code to be improved by 
doing what current kernels do for that function. They now have a WARN_ONCE 
message that goes to syslog. That keeps the audit logs cleaner.

-Steve

  reply	other threads:[~2014-08-15 18:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-14 20:12 Backlog exceeded when using audisp Andy Ruch
2014-08-15 18:01 ` Steve Grubb [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-08-13 21:37 Andy Ruch
2014-08-14 12:50 ` Steve Grubb

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=13673462.7keNk3W44N@x2 \
    --to=sgrubb@redhat.com \
    --cc=adruch2002@yahoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox