Running multiple audit service clients

Running multiple audit service clients

[Max Timchenko]

[-- Attachment #1.1: Type: text/plain, Size: 690 bytes --]

Dear all,

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. 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.

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?

Yours,
-- 
Max

[-- Attachment #1.2: Type: text/html, Size: 968 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Running multiple audit service clients

[Richard Guy Briggs]

On 16/02/10, Max Timchenko wrote:
> Dear all,
> 
> 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. 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.
> 
> 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?

With recent changes upstream, the second would be denied with -EEXIST.

Before that, the older one would be starved out.  And versions even
older might actually have the newer one orphaned in the very occasional
race where the older one shuts down after the second one starts.

To quote Highlander, "There Can Be Only One".

There is also planning to be done to allow one auditd per user
namespace to support containers, but we aren't there yet.

> Max

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Re: Running multiple audit service clients

[Paul Moore]

On Wed, Feb 10, 2016 at 9:30 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> There is also planning to be done to allow one auditd per user
> namespace to support containers, but we aren't there yet.

To add to that, we will also provide better support for containers
with a single auditd instance (the microservices case) by providing
better marking of audit records to help indicate which namespace set
(what the kernel would consider a container) generated the audit
event.

-- 
paul moore
www.paul-moore.com

Re: Running multiple audit service clients

[Max Timchenko]

[-- Attachment #1.1: Type: text/plain, Size: 1369 bytes --]

On Wed, Feb 10, 2016 at 9:30 PM, Richard Guy Briggs <rgb@redhat.com> wrote:

> On 16/02/10, Max Timchenko wrote:
> > 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?
>
> With recent changes upstream, the second would be denied with -EEXIST.
>
> Before that, the older one would be starved out.  And versions even
> older might actually have the newer one orphaned in the very occasional
> race where the older one shuts down after the second one starts.
>
> To quote Highlander, "There Can Be Only One".
>

Thanks Richard and Paul for your quick responses. It's great to hear that
support for
containers is being worked on.

I have read the docs on audispd(8) - is it something auditd and the other
client could use to enable multiple access? It sounds like audispd does
support
multiple clients, but I would guess all clients would have to use the
audispd plugin
interface instead of the usual kernel API.

What is missing from the documentation for me is the relationship between
audispd
and auditd - whether audispd is an optional component of auditd that can
run
concurrently, or audispd is a replacement of auditd when configured
(and then auditd cannot run on the same machine
without running into the same multi-client issues).

Yours,
--
Max

[-- Attachment #1.2: Type: text/html, Size: 2289 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Running multiple audit service clients

[Richard Guy Briggs]

On 16/02/11, Max Timchenko wrote:
> On Wed, Feb 10, 2016 at 9:30 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> > On 16/02/10, Max Timchenko wrote:
> > > 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?
> >
> > With recent changes upstream, the second would be denied with -EEXIST.
> >
> > Before that, the older one would be starved out.  And versions even
> > older might actually have the newer one orphaned in the very occasional
> > race where the older one shuts down after the second one starts.
> >
> > To quote Highlander, "There Can Be Only One".
> 
> Thanks Richard and Paul for your quick responses. It's great to hear
> that support for containers is being worked on.
> 
> I have read the docs on audispd(8) - is it something auditd and the
> other client could use to enable multiple access? It sounds like
> audispd does support multiple clients, but I would guess all clients
> would have to use the audispd plugin interface instead of the usual
> kernel API.
> 
> What is missing from the documentation for me is the relationship
> between audispd and auditd - whether audispd is an optional component
> of auditd that can run concurrently, or audispd is a replacement of
> auditd when configured (and then auditd cannot run on the same machine
> without running into the same multi-client issues).

I will defer to Steve Grubb on this quesition as the userspace tools are
his domain of expertise.

> Yours,
> --
> Max

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Re: Running multiple audit service clients

[Steve Grubb]

On Thursday, February 11, 2016 03:19:27 PM Max Timchenko wrote:
> I have read the docs on audispd(8) - is it something auditd and the other
> client could use to enable multiple access? It sounds like audispd does
> support multiple clients, but I would guess all clients would have to use
> the audispd plugin interface instead of the usual kernel API.

Yes. This is intentional and has existed for about 10 years.


> What is missing from the documentation for me is the relationship between
> audispd and auditd - whether audispd is an optional component of auditd that
> can run concurrently

Yes. If you look in auditd.conf, you will see that there is a configuration 
option, dispatcher, which allows you to select another consumer of audit 
events. Normally the selection of /sbin/audispd is the best because it allows 
"unlimited" multiplexing of the audit stream.

You can send events to syslog, setroubleshoot, and remotely log events in an 
aggregator all at the same time.


> , or audispd is a replacement of auditd when configured
> (and then auditd cannot run on the same machine
> without running into the same multi-client issues).

No. The audispd man page says, "audispd is an audit event multiplexor. It has 
to be started by the audit daemon in order to get events."

HTH...

-Steve

Re: Running multiple audit service clients

[Steve Grubb]

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