From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Backlog exceeded when using audisp Date: Fri, 15 Aug 2014 14:01:22 -0400 Message-ID: <13673462.7keNk3W44N@x2> References: <1408047139.57007.YahooMailNeo@web120702.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1408047139.57007.YahooMailNeo@web120702.mail.ne1.yahoo.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com, Andy Ruch List-Id: linux-audit@redhat.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