Re: Using the audit system for non-security events
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit