Re: Audit for live supervision
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