Auditd framework slowdowns (sometimes freezes) the entire system.

[Steve Grubb]

On Tuesday, July 21, 2015 01:23:49 PM Kangkook Jee wrote:
> With our custom audit client, we prefer not to take too much resources (CPUs
> or memory) from user machine and rather want to drop some events.

Maybe set a smaller backlog and tell it to ignore overflows?

-b 512
-f 0


> Therefore I'm trying to use audit multicast feature you mentioned
> (https://lwn.net/Articles/587166/). I found out that this feature is
> recently added and I have a few questions using it.
> 
> Q1. I've gone over journald source code and found out that it issues a
> number of netlink socket api calls to join in multi-cast group and receive
> datagrams. Do you support rather cleaner api to use this feature? I
> couldn't find anything from libaudit.h.

This is one for the kernel developers.

> Q2. By joining in audit multi-cast group, can we avoid auditing the audit
> client itself? As you know, with audit_set_pid(), it prevents from
> gathering and reporting audit event for user-space audit client. We can
> expect the same thing?

You can set a rule once your program starts up and you have access to your 
pid. It would be the equivalent of this:

-a never,exit -S all -F pid=<pid>


> Q3. By only having a read-only user-space audit client and not having
> bi-direction audit client running from the system,  are we going to see
> audit entries logged from default system log frameworks which output to
> /var/log/kernel.log (Debian family), syslog, or dmesg?

You should not. I know you said you looked at Journald as an example of how to 
do it. It might be joining a lot more than audit. I haven't looked.

 
> Q4. Our environment for deployment comprises many different types of legacy
> distributions (i.e., CentOS 5 or 6, Ubuntu 12.04 ...), could you inform me
> from what audit version (or kernel version) audit multicast is supported?

It seems to be 3.16.

 
> Q5. I'm also considering another design choice to use *rate_limit* to limit
> the amount of audit messages delivered to user-level client. Do you think
> kauditd will drop some messages with this setting enabled?

I have not played with it. Maybe one of the kernel developers has an opinion. 
I am pretty sure you can just ignore queue overflows, though.
 
-Steve