Re: Kernel audit output is inconsistent, hard to parse

[Paul Moore <paul.moore@hp.com>]

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