Kernel audit output is inconsistent, hard to parse

[Paul Moore]

On Wednesday 30 January 2008 11:01:09 am Steve Grubb wrote:
> 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.

You cut out my comment that said, "We need to remember that backwards 
compatibility is a requirement for improvement, not a reason to block 
improvement.".  There are ways to introduce new/improved behavior while 
preserving old behavior during a transition period.  Throwing your arms up 
and saying we can't make any changes is ... well, lazy to be honest.

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

Okay, I'm going to drop this point then.

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

I understand this is not a new issue and you have tried many a time in the 
past only to run into a brick wall.  I'm sensitive to that, I really am, but 
I think there is still an opportunity to find a better solution.

> But they are a separate community from us.

... that plays in the same sandbox.  It's not really an "us versus them" 
issue, it's more of a "plays well with others" thing.  We need to find out, 
in detail, what they object too and then work around it in a systematic and 
persistent manner.  Regardless, let's drop this point for the time being as 
it is a distraction to the greater issue being discussed.

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

Think in more general terms right now ... we need to figure out what we want 
the new solution to be before we figure out how to make it compatible.

-- 
paul moore
linux security @ hp