Re: Kernel audit output is inconsistent, hard to parse

[John Dennis <jdennis@redhat.com>]

Eric Paris wrote:
> On Tue, 2008-01-29 at 17:56 -0500, John Dennis wrote:

> I'm certainly not going to argue this isn't problomatic.  I believe that
> case #1 should go away.  Maybe when I get back from Chile I'll get a
> chance to look at that.  Some fields just aren't ever strings, so I
> don't see a need to waste time/space writing " around something I know
> is always an int.  But if the field can be a string it should ALWAYS be
> either case 2 or 3.

I'm cool with not using quotes around everything, I very much see the 
appeal in that. But if you do that then *all* strings have to be quoted 
*and* you can't continue to use the current unquoted hexadecimal string 
encoding (case 3), it's ambiguous, you can't determine if its a string 
because the quotes would be missing. That means case 3 also must be 
eliminated. All strings have to be enclosed in quotes and what appears 
inside the quotes has to support encoding arbitrary bytes. FWIW 
backslash quoting meets this requirement, as does many other encodings 
in popular use.

> It "shouldn't" depend on the kernel version, but I'm sure it does.  I'm
> going to work on eliminating case 1, which makes a lot of this mute.

Eliminating both case 1 and case 3 would be necessary to make it moot. 
It would be a superb step forward and greatly appreciated.

> What approach would you like when I try to audit binary data?  You want
> me to start adding \x before every byte?  Forget it, waste of space.

Encoding binary data is solved problem. Some encodings are more 
efficient than others, pick a standard encoding which satisfies your 
requirements. The only key is that when the input stream shifts into and 
out of encoded format it must be determinable only from the input 
stream. It cannot rely on private version specific knowledge that 
certain fields have this encoding.

> I don't want to waste time/effort having to write res="1" when I can
> just say res=1.  I know you are complaining that you have to look at
> message type, field name, and kernel version.  My opinion, you should
> just have to look at field name.

I shouldn't have to look at the field name, this violates basic parsing 
rules and is tied to specific kernel versions, see first comment, there 
is an easy solution.

> I've got no problems eliminating all of the %s in the code and making
> everything go through audit_log_string()

That would be a big step forward and would solve many of the problems, 
thanks. Just be aware audit_log_string has to use a different encoding 
other than bare hexadecimal.

> My take, if the field name is something that can be a string you either
> get field="string" or you get field=737472696e67.  Either way its easy
> to recognize.  Quotes means string, no quotes means hex.

How does the parser know the field can be a string? See above.

-- 
John Dennis <jdennis@redhat.com>