From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linda Knippers Subject: Re: Using the audit system for non-security events Date: Tue, 27 May 2008 15:11:26 -0400 Message-ID: <483C5CDE.4050106@hp.com> References: <1211911726.3079.35.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1211911726.3079.35.camel@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: linux-audit@redhat.com, dwmw2@redhat.com, harald@redhat.com List-Id: linux-audit@redhat.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