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 > [email protected] > https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
