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