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

[Klaus Heinrich Kiwi <klausk@linux.vnet.ibm.com>]

On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote:
> 
> And any code created needs to be backwards compatible. you could have new user 
> space/new kernel, or new user space/old kernel, and new kernel/old user 
> space. You have no way of dictating which versions of anything people will 
> use.

But isn't this the exact situation we face now? I remember people asking
in this list about audit for RHEL4, and in the end the problem was that
they had their kernel upgraded so userspace and kernel were not in
sync...

I think that if we take this discussion to extremes, we'd be talking
about a 'self-descriptive meta language' so that upgrades to
userspace/kernel are well covered (can you say "xml"?)

On the other hand, I do agree that the way it's currently implemented is
prone to error when it comes to reporting/analyzing data. e.g., I
remember fixing a 'mode' field in an audit object where it was being
displayed as hex where we would expect an octal. In the future, when
parsing this field, how would I know which radix a mode=003 field is?
Fundamentally, was the record generated in patched kernel or not? If we
take this change applied to every kernel and userspace change of the
audit records, how can auparse possibly cover all cases?

I also feel that stricter message format rules for userspace would help.
Nowadays is difficult to 'reconstruct' the meaning of an audit record
just by looking at their fields. Some fields don't even have a value,
other use the same field twice in the same record. And for most people
wanting to analyze audit data the fields=value pairs are the only
reliable source.

-Klaus

-- 
Klaus Heinrich Kiwi <klausk@linux.vnet.ibm.com>
Linux Security Development, IBM Linux Technology Center