From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Wed, 13 Aug 2008 15:35:40 -0700 Message-ID: <48A361BC.6010403@schaufler-ca.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <48A1EB72.6070607@redhat.com> <1218571902.3540.2.camel@localhost.localdomain> <200808121632.55341.sgrubb@redhat.com> <1218587598.3437.23.camel@klausk.br.ibm.com.br.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 m7DMa64A017364 for ; Wed, 13 Aug 2008 18:36:06 -0400 Received: from smtp101.prem.mail.sp1.yahoo.com (smtp101.prem.mail.sp1.yahoo.com [98.136.44.56]) by mx3.redhat.com (8.13.8/8.13.8) with SMTP id m7DMZs0D028953 for ; Wed, 13 Aug 2008 18:35:55 -0400 In-Reply-To: <1218587598.3437.23.camel@klausk.br.ibm.com.br.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Klaus Heinrich Kiwi Cc: William Kelly , Bret Piatt , linux-audit@redhat.com List-Id: linux-audit@redhat.com Klaus Heinrich Kiwi wrote: > On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote: > >> And any code created needs to be backwards compatible. you could have new user >> space/new kernel, or new user space/old kernel, and new kernel/old user >> space. You have no way of dictating which versions of anything people will >> use. >> > > But isn't this the exact situation we face now? I remember people asking > in this list about audit for RHEL4, and in the end the problem was that > they had their kernel upgraded so userspace and kernel were not in > sync... > > I think that if we take this discussion to extremes, we'd be talking > about a 'self-descriptive meta language' so that upgrades to > userspace/kernel are well covered (can you say "xml"?) > Before y'all go laughing too hard at this suggestion, the Irix audit trail format is a 'self-descriptive meta language' that only misses being XML by having preceded XML by a year or two. > On the other hand, I do agree that the way it's currently implemented is > prone to error when it comes to reporting/analyzing data. e.g., I > remember fixing a 'mode' field in an audit object where it was being > displayed as hex where we would expect an octal. In the future, when > parsing this field, how would I know which radix a mode=003 field is? > Fundamentally, was the record generated in patched kernel or not? If we > take this change applied to every kernel and userspace change of the > audit records, how can auparse possibly cover all cases? > > I also feel that stricter message format rules for userspace would help. > Nowadays is difficult to 'reconstruct' the meaning of an audit record > just by looking at their fields. Some fields don't even have a value, > other use the same field twice in the same record. And for most people > wanting to analyze audit data the fields=value pairs are the only > reliable source. > > -Klaus > >