Audit for live supervision

[Kay Hayen]

Hello Steve,

> > Well for the functionality of ausyscall. If we could query the current
> > arch, well it's b32/b64 arches, then we could build that table at run
> > time, couldn't we?
>
> Sure. If you look at the code for ausyscall, it simply calls
> audit_syscall_to_name() in libaudit. On number to string its a straight
> lookup, for string to number, we have to brute force search for it.

Perfect, we are going to use that instead then.

> > > > > We have an audit parsing library. It takes this into account.
> > > >
> > > > I have looked at it, and auparse_init doesn't seem to support reading
> > > > from the socket itself, does it?
> > >
> > > You mean the netlink socket?
> >
> > 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?
>
> Not directly because the audit internal API has the type as an integer
> separate from the text of the event. Its really simple to create a string
> that auparse can use and then use the feed interface. A working example of
> the feed interface can be found in audisp/plugins/prelude/audisp-prelude.c.

Nice, as I wrote in that other email of mine shortly ago, this could well be 
the way forward for now and later we can switch to pure netlink socket.

> > > libaudit should pull complete events from the kernel unless an execve
> > > has an excessive number of arguments or large sized arguments.
> >
> > 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?
>
> True. You would have to load your own rules since that is done by the audit
> user space.

Can you confirm that two processes opening netlink sockets for audit 
information get the same messages? I am under the impression that the kernel 
doesn't maintain per socket configuration, does it?

If that were the case, we would simply co-exist with auditd and let it do its 
logging, etc. and benefit from it, and its ability to load the rules (which 

> events. 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's very sweet. Where would you expect the pitfalls? I mean, it can't be so 
easy. :-)

> The audispd feeds data to siblings. In the configuration file, you 
> just specify that the child app wants string data and it takes care of  the
> conversion. The prelude plugin is a good example. However, audispd plugins
> are probably too high of latency for you. Converting the kernel's data into
> a string is simple as code snippet above shows.

Given that all we would have to do is to open the socket and listen, feed 
what's received on it to asprintf and get our callbacks called for events, it 
sounds very simply indeed.

We will have a look at this too, seems from code complexity there barely would 
be a difference, so taking the full jump immediately might be an option as 
well. I will report on that too.

Best regards,
Kay Hayen