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

[Casey Schaufler]

Klaus Heinrich Kiwi wrote:
> 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"?)
>   

Before y'all go laughing too hard at this suggestion, the Irix
audit trail format is a 'self-descriptive meta language' that only
misses being XML by having preceded XML by a year or two.

> 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
>
>