Re: Audit for live supervision

[Kay Hayen <kayhayen@gmx.de>]

Hello John,

Am Dienstag, 19. August 2008 16:14:54 schrieb John Dennis:
> Kay Hayen wrote:
> > No, when opening the socket the to the sub deamon audisp. I couldn't
> > convice myself how the API would work with a socket. Does it?
>
> The auparse library can read a stream by opening the parser with
> AUSOURCE_FEED, you set a callback, then feed arbitrary number of bytes
> into the parser by calling auparse_feed(), you'll be called back when a
> complete event is found, at that point just use the normal auparse
> functions.
>
> You can read off of this unix socket (/var/run/audispd_events) but this
> is deprecated. It is now preferred is now to use a audispd plugin and
> read from stdin. See the audit src package and look in audisp/plugins
> for examples. FWIW I noticed that code was calling fgets to get data to
> feed to auparse_feed() but it seems inefficient to buffer lines twice,
> auparse_feed will do the line protocol.

That's great. We can use the first approach initially (unix socket), a plugin 
is not so good for us, because our supervision process would need to receive 
from it anyway. 

The next best step would be to use the netlink socket directly. From what 
Steve wrote, that doesn't seem entirely difficult either:

Steve wrote:
> wrt auparse (if that's what you meant) you just run the data through:

> asprintf(&v, "type=%s msg=%.*s\n", type, e->hdr.size, e->data);

> and "v" has the string ready for auparse use. asprinf() allocates memory, so 
> watch that it doesn't create a memory leak.

That seems pretty direct too. If it's that easy to use auparse with either 
audisp socket or netlink socket, all the blame on us for not discovering it 
on our own. :-)

The extra handling of the netlink socket may not be that much code then, 
allthough I suspect it requires a root rights (or simply a capability I would 
hope).

> > I read that as that we can use the netlink socket with the libaudit
> > directly, which sort of could be exactly what we want. That would mean we
> > wouldn't use audit user space (processes) at all, right?
>
> No, you really want to use the user space interface (see above).

Well, for lowest latency possible (note the "live" in subject), it would be 
ideal to avoid context switches auditd -> audisp -> our supervisor and 
instead simply run an additional netlink socket in addition to auditd (if 
that is allowed). That way we would have a lot less latency, at least in 
theory.

But that could well be a final step only and future work and be judged by 
measurements of what we get from the relatively easy solution. I am going to 
try out that approach of AUSOURCE_FEED and report.

Best regards,
Kay Hayen