Performance of libauparse

[Paul Moore]

On Wednesday 01 October 2008 3:20:13 pm LC Bruzenak wrote:
> On Wed, 2008-10-01 at 14:38 -0400, Paul Moore wrote:
> > On Wednesday 01 October 2008 9:15:27 am Eric Paris wrote:
> > > On Tue, 2008-09-30 at 15:18 -0400, John Dennis wrote:
> > > > Eric likes to point out we can't change the
> > > > kernel
> > >
> > > Close, but not quite.  I say we can't change the kernel without
> > > complete backwards compatibility.  Show me the right solution and
> > > we can get there, we just can't throw away what's already there.
> >
> > Not really aimed at anyone in particular, just throwing out a
> > possible solution ...
> >
> >  1. By default kernel starts up and emits existing string format,
> > legacy audit daemons function normally
> >  2. If a new audit daemon starts it sends a message to the kernel
> >     indicating that it can handle the new format and the kernel
> > starts emitting newly formatted records[1]
> >  3. The new audit daemon records the audit records in whatever
> > format it is configured to so: legacy string format, raw binary
> > format, and/or some wacky format yet to be invented[2]
> >
> > [1] The new record format should probably a binary format which
> > makes use of netlink attributes, this would avoid much of the
> > string parsing and versioning problems we have seen previously. 
> > There is ample evidence of kernel subsystems using netlink in a
> > similar fashion successfully.
> >
> > [2] If done carefully, we might be able to allow administrators to
> > create their own on-disk string formats without the need to write
> > an entire dispatcher plug-in.
>
> This isn't a vote against (since I haven't fielded yet), but I could
> see it could throw the user-space tools a curve (especially option
> [2]) regarding legacy data.

Exactly why the system needs to be backwards compatible; you stick with 
the old format until your tools support a newer format.  However, if 
you are talking the base audit userspace tools, I would expect those to 
be updated in sync with an update audit daemon so it should be more of 
3rd party issue.

The nice bit about shipping binary events to userspace is you can create 
whatever format you want.  Ideally there would be a way for audit 
plugins to see the events in binary format which opens things up even 
more.

> Might have to register the format spec inside the log file?

Sure.  Why not.  Once you abstract the representation of the data from 
the data itself you can do whatever you want with much less fuss.  We 
can even stop worrying about all this string escaping sillyness that 
seems to never die.

[NOTE: I'm grabbing your other mail and replying to it here]

> Oh, another thing which would (potentially) get harder is
> aggregation. Since we have aggregated audit data sent from one
> audisp-remote to the event loop of the aggregating auditd, both
> systems (kernels) would need to be on the same data format page.

Yep.  Or you just pass around the binary format and you never have to 
worry about formatting, just new field types and honestly there are 
easy solutions around that as well.

-- 
paul moore
linux @ hp