From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Using the audit system for non-security events Date: Tue, 27 May 2008 14:08:46 -0400 Message-ID: <1211911726.3079.35.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: dwmw2@redhat.com, harald@redhat.com List-Id: linux-audit@redhat.com 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. 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. 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? -Eric