Re: get_field_str() and interpret_field() bug with multi-word fields

[John Dennis <jdennis@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1989 bytes --]

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>


[-- Attachment #1.2: Type: text/html, Size: 2557 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]