Re: Kernel audit output is inconsistent, hard to parse
On Wednesday 30 January 2008 9:21:34 am Steve Grubb wrote:
On Tuesday 29 January 2008 17:56:36 John Dennis wrote:
> The bottom line is one cannot parse the audit messages without special
> case knowledge of each audit message because the data formatting does
> not follow any regular rules.
Hence the audit parsing library. The idea is to abstract this away so that
anyone wanting to write a tool does not need to study all the messages and
figure out the parsing rules.
The way forward has to be the audit parsing library. At this point, there
are tools developed around these messages and making wholesale changes will
break them.
Okay, while userspace backwards compatibility is a valid and important
concern, using it as reason to prevent fixing problems such as this is bad.
We need to remember that backwards compatibility is a requirement for
improvement, not a reason to block improvement. I'm not as much of an audit
expert as some of the people on this list, but I'm certain there is a
workable solution here, we just need to think harder and more creatively.
That said, don't take my comments to mean that I disagree with a userspace
library to parse audit events, I think that is a good idea. What I think is
a bad idea is using it as an excuse to fix the kernel.
This is the reason that the SE Linux messages are such a mess.
I've raised my concern with the developers on the selinux mail list and
they essentially told me they are not willing to make any changes. But they
did agree to some keywords for the fields you mention so that we could go
ahead and code tools.
I have a sneaking suspicion that if we made audit work better we could also
make it work better for SELinux.
> Most of these problems can easily be fixed if there is exactly
one
> central place to format an audit field value.
This is what we've done with user space. As for the kernel, essentially
there is no maintainer or anyone interested in doing audit work. I pretty
much have to force people to touch it. So, good luck getting kernel work
done.
I thought you/Eric/Al were the maintainer(s)? No? Okay, fine.
If that really is the problem I'll throw my hat into the ring and volunteer to
maintain the kernel code. I'm not an audit expert but I learn quickly and
I'm very allergic to people saying "we can't do/fix that". John brought
up
some really good points and I think dismissing them so quickly is doing a
disservice to audit and the community.
> Auparse is not the answer:
> --------------------------
>
> Auparse is not the answer to irregular kernel audit message
> formatting. First of all it forces auparse to have special case logic
> which is not 100% robust and is tied to the kernel source code
> version.
This is the answer in so many ways. In order to make any change, you have
to decouple applications from the actual data structure. You cannot
normalize the data without breaking somebody somewhere.
That is why we have compatibility "modes", second versions that run in
parallel, etc. While this problem may be new to audit, it is not new to the
kernel or other software projects; it _is_ a solvable problem, it just
requires some of that "hard work".
--
paul moore
linux security @ hp