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>