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

[Eric Paris]

On Tue, 2008-08-12 at 21:33 -0300, 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...

As I recall in the RHEL4 case the problem was the RH was carrying their
own audit patches and so we didn't have to deal with upstream policies.
Look at how strict those upstream policies.  It doesn't even matter if
backwards compatibility for BUGS are broken, new kernel + ancient
userspace MUST be able to work somehow.

> 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"?)

HAHAHA, kernel output xml?  dream on   :)   I'm willing to do wholesale
output changes, but something that heavy in kernel is impossible to
push.  I can just see Al cussing up a storm as he read that.

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

I'm all for this, but I still firmly believe that if I am a user of the
audit subsystem and I decide to use my own ugly format that completely
sucks its not audit's fault when it can't parse those things.  aka if
you can't use auparse to look at SELinux records, too bad, that's
SELinux's problem to parse them.  But everything the audit system
controls could and should be moved to a better standard.

-Eric