Re: Kernel audit output is inconsistent, hard to parse
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