From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Tue, 12 Aug 2008 17:40:00 -0400 Message-ID: <48A20330.7090206@redhat.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <1218571902.3540.2.camel@localhost.localdomain> <48A1F957.8070501@redhat.com> <200808121718.36331.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0215468035==" Return-path: In-Reply-To: <200808121718.36331.sgrubb@redhat.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: Steve Grubb Cc: William Kelly , linux-audit@redhat.com, Bret Piatt List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============0215468035== Content-Type: multipart/alternative; boundary="------------070705010604030005070101" This is a multi-part message in MIME format. --------------070705010604030005070101 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Steve Grubb wrote: > On Tuesday 12 August 2008 16:57:59 John Dennis wrote: > >> Let me give you a simple example, suppose this key/value pair was in an >> audit record: >> >> foo=00 >> >> How does one know which of the possible values foo has: >> >> 1) it's the integer zero (but in what radix? does the leading zero imply >> octal or is it just an insignificant digit?) >> >> 2) it's the hexadecimal encoding of a single character string containing >> one null byte. >> >> 3) it's the 2 character string "00" consisting of two zero characters. >> >> The fact is it's ambiguous, it could be any of the above. It's ambiguous >> because the audit stream is an improperly specified protocol. >> > > John, this is the way that the kernel works. The kernel and user space > utilities that interface to it are developed together with an understanding > of how the numbers are represented. Go take a look in /proc/1/stat. What does > any of that mean? Is it parsable? I'll guarantee its defined well enough > program can use it. > Bad example, proc works because it's (mostly) well defined. Sorry, but the audit stream is not well defined, it can change at any time. We have existence proofs of it changing. That doesn't even take into account "user audit data". A properly specified protocol is immune to these problems. > 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 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. -- John Dennis --------------070705010604030005070101 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Steve Grubb wrote: 
On Tuesday 12 August 2008 16:57:59 John Dennis wrote:
  
Let me give you a simple example, suppose this key/value pair was in an
audit record:

foo=00

How does one know which of the possible values foo has:

1) it's the integer zero (but in what radix? does the leading zero imply
octal or is it just an insignificant digit?)

2) it's the hexadecimal encoding of a single character string containing
one null byte.

3) it's the 2 character string "00" consisting of two zero characters.

The fact is it's ambiguous, it could be any of the above. It's ambiguous
because the audit stream is an improperly specified protocol.
    

John, this is the way that the kernel works. The kernel and user space 
utilities that interface to it are developed together with an understanding 
of how the numbers are represented. Go take a look in /proc/1/stat. What does 
any of that mean? Is it parsable? I'll guarantee its defined well enough 
program can use it.

Bad example, proc works because it's (mostly) well defined. Sorry, but the audit stream is not well defined, it can change at any time. We have existence proofs of it changing. That doesn't even take into account "user audit data". A properly specified protocol is immune to these problems.
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 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.
-- 
John Dennis <jdennis@redhat.com>
--------------070705010604030005070101-- --===============0215468035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0215468035==--