On Wednesday, February 10, 2016 04:28:26 PM Max Timchenko wrote:
I have a situation where there are two audit clients on the same
machine:
one of them is auditd, and another one is an IDS client that uses the audit
subsystem directly.
It should not be designed that way. For compliance purposes many people have
to save the audit logs. I have given several speeches on how to do this so
that everyone has a correct model to work from. The latest speech on audit+IDS
is here:
http://people.redhat.com/sgrubb/audit/audit_ids_2011.pdf
The main idea is that auditd has a builtin facility for sharing events,
auditspd. The IDS system can clip into it and get the event stream. If it
wants events as they come "off the wire" they should set the format option to
BINARY and they will get it exactly as it was handed to auditd. More typical
is to use STRING format so that they can use auparse to dissect the event for
processing.
By looking at the source (
http://lxr.free-electrons.com/source/kernel/audit.c?v=3.13#L787), I suspect
that there might be no provision in the kernel for multiple audit subsystem
userland daemons running in parallel (only one pid, only one netlink socket
in the kernel). I could not find any documentation confirming or denying
that.
There is not. Nor should there be. With the ease in which analysis programs
can get the audit stream, they should not have to resort to exclusive access.
For example, setroubleshooter plugin puts something in /etc/audisp/plugins.d/
so that it can see events in realtime. Its a good example of "doing it right".
Has anyone tried that before? What would actually happen if two
different
audit clients tried to use the same interface to the audit subsystem in the
kernel?
Last one wins.
-Steve