Failure flag "0" doesn't work

[Steve Grubb]

On Friday, August 21, 2015 08:15:41 AM Burn Alting wrote:
> One assumes the audit_failure variable has been set in the kernel
> (kernel/audit.c). Perhaps you can test this.

Yes, that is where it gets written to.
 
> Given you can get a copy of the kernel source you are running, perhaps
> trace through what's happening. Using the messages
> before/during/directly after the death of auditd, and what's routing to
> dmesg, perhaps you can reverse engineer what is happening.
> 
> Perhaps someone else on the list can explain why, given -f is set to 0,
> and the kernel has no user space destination for audit, it still prints
> (via printk()?)

The explanation of what the failure flag does is explained in the auditctl man 
pages:

"This option lets you determine  how  you  want  the kernel to handle critical 
errors. Example conditions where this mode may have an effect  includes:               
transmission  errors  to  userspace  audit daemon, backlog limit exceeded, out 
of kernel memory, and  rate  limit  exceeded."

Note that dead audit daemon is not included in what it covers.


> On Thu, 2015-08-20 at 13:17 +0300, Alex Beljanski wrote:
> > We have custom audit-dispatcher for process events. On some servers
> > when auditd fails, all audit messages writes to kernel.

This is expected when the audit system is enabled.


> > We don't want to see all this messages in dmesg and set failure flag
> > to "0". This doesn't help.

Correct. For _events_ to not be written to syslog, the audit system has to be 
disabled. You would run "auditctl -e 0" to turn off the audit system. OR if you 
are using rsyslog, then you can probably write a filter so that it removes 
audit events as it finds them.

-Steve