From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Kernel audit output is inconsistent, hard to parse Date: Thu, 31 Jan 2008 16:59:27 -0500 Message-ID: <200801311659.28042.paul.moore@hp.com> References: <479FAF24.8050109@redhat.com> <47A2398A.2050309@hp.com> <200801311621.37931.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m0VM08Xd025035 for ; Thu, 31 Jan 2008 17:00:08 -0500 Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id m0VLxZHw019181 for ; Thu, 31 Jan 2008 16:59:35 -0500 Received: from g1t0028.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id B7BDA1C2F0 for ; Thu, 31 Jan 2008 21:59:29 +0000 (UTC) Received: from mailstation.cce.hp.com (mailstation.zcce.gate.cpqcorp.net [16.104.192.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTP id B28841C1FD for ; Thu, 31 Jan 2008 21:59:29 +0000 (UTC) Received: from stuffed.lan (c-24-61-189-47.hsd1.nh.comcast.net [24.61.189.47]) by mailstation.cce.hp.com (Postfix) with ESMTP id C0BA1C07F for ; Thu, 31 Jan 2008 16:04:00 -0600 (CST) In-Reply-To: <200801311621.37931.sgrubb@redhat.com> Content-Disposition: inline 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 List-Id: linux-audit@redhat.com On Thursday 31 January 2008 4:21:37 pm Steve Grubb wrote: > On Thursday 31 January 2008 16:11:38 Linda Knippers wrote: > > At one time we talked about converting to a binary record format. > > At this point, I want things stable. I've spent the last 3 years working on > the foundation to the audit system and we need to focus higher up the stack > for a while. There's all kinds of neat things we can do if we don't keep > reworking the bottom layer. :) ... Neat things like building castles on the sand? ;) (Sorry, couldn't resist!) -- paul moore linux security @ hp