Kernel audit output is inconsistent, hard to parse

[Steve Grubb]

On Wednesday 30 January 2008 10:34:00 Paul Moore wrote:
> 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,

That is what blocks any change. As long as we have apps that do their own 
parsing, we will break them all.


> 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.

That's not what i was saying. I said that using it is the way to allow changes 
to be made. We need to decouple the data representation from the apps, then 
we can tinker under the hood and make changes to just 1 library so that 
everything still works. If we don't, you will have to fixup all apps that 
parse audit data directly. (Which will be broken soon anyways.)


> > 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.

Only if you had a willingness for them to change their tools. Last time I 
checked, they weren't interested as it would introduce a lot a rework for a 
problem they don't care about. Feel free to point out their format doesn't 
follow our convention. If you can convince them to change, super. I couldn't. 
I agree that it would be nice if they could make some changes. But they are a 
separate community from us.


> > > 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.

I'll let them speak for themselves. I review the code and have a wishlist that 
I can sometimes get people to work on. Sometimes I do the work when no one 
else will.


> > 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",

So are you suggesting that a new auditctl command be introduced to tell the 
kernel to leave AVC's the way they are?

-Steve