Re: Using the audit system for non-security events

[Linda Knippers <linda.knippers@hp.com>]

Eric Paris wrote:
> The userspace group is attempting to write new applications which will
> dynamically profile system startup and preload applications and data so
> that they are hot in the kernel when they are needed.
> 
> http://fedoraproject.org/wiki/Features/30SecondStartup/ReadAheadReloaded
> 
> They need to see all of the exec and open calls from the system so they
> can profile what is needed.  They discovered that the audit system does
> exactly what they need except one problem.  It writes all of the exec
> and open call records to disk which very quickly gets too large.  All
> they want is a way to tell the audit system to send a message to the
> audit dispatcher but not to log to disk.  This isn't so easy as it means
> that audit has to somehow parse the messages rather than just quickly
> write them.

Do these folks also want to run audit for security-related events?  If
not, then they could just configure a small audit file or two that
wraps/rotates, or use the NOLOG log format.

> Since the plan is to always have the audit system always emit these
> rules on all non-server type systems it really isn't reasonable to have
> them written to disk.  We suggested they look at system-tap, which was
> able to give them the information, but it meant compiling a kernel
> module for every kernel and had all sorts of maintenance nightmares
> (from what I'm told) so they came back to me.
> 
> What I'm considering is a new 'flag' which audit rules can be loaded
> with which indicates to use the new 'no-log' netlink socket.  The kernel
> would then have 2 netlink sockets.  One will continue to talk to auditd
> the other straight to a dispatcher.  No changes will be made in any way
> to the way we handle messages or panic on message loss to the 'normal'
> audit queue.  I'm thinking the second netlink socket will be a 'best
> effort' audit system.  Messages may be dropped without indication it
> should run at a lower priority, blah blah blah.  It would allow the very
> flexible and powerful audit system to be used for profiling and data
> collection for non-security relevant applications.

Is that what we want?  Would it be better to work on a way to solve
their maintenance nightmare with systemtap?

> I want thoughts on such a proposal.  Obviously I'm going to ahve to put
> some real thought/care into how to handle 'overlapping' rules between
> security and non-security and stuff like that, but as a general idea
> what do people think?

Sounds complicated, but you knew that already.

-- ljk
> 
> -Eric
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit