From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Tue, 12 Aug 2008 17:53:09 -0400 Message-ID: <200808121753.10501.sgrubb@redhat.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <200808121718.36331.sgrubb@redhat.com> <48A20330.7090206@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48A20330.7090206@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: John Dennis Cc: William Kelly , linux-audit@redhat.com, Bret Piatt List-Id: linux-audit@redhat.com On Tuesday 12 August 2008 17:40:00 John Dennis wrote: > Bad example, proc works because it's (mostly) well defined. What does the 25th field in /proc/1/stat mean? You can't tell without looking at the kernel source code. > > The point is that all of /proc is written without implicit parsing rules. > > That's the way it is when dealing with kernel and its user space > > utilities. There is no field in the kernel that is unhandled by the audit > > system and without knowing specifically what's in it. > > I'm sorry Steve, but this simply doesn't work. How the heck am I > supposed to correctly parse an audit log file from 5 years ago if either > I don't know the kernel version that produced it ausearch --start today -m DAEMON_START ---- time->Tue Aug 12 08:03:52 2008 node=127.0.0.1 type=DAEMON_START msg=audit(1218542632.238:4562): auditd start, ver=1.7.4 format=raw kernel=2.6.26-0.17.rc3.sg3.fc9.x86_64 auid=4294967295 pid=2139 res=success > or have available the matching user space tools from that era? This is going > to be an absolute nightmare for IPA and other compliance tools. With backwards compatibility you don't have to worry about having tools of that era. -Steve