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

From: Linda Knippers <linda.knippers@hp.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: William Kelly <wkelly@rackspace.com>,
	linux-audit@redhat.com, Bret Piatt <bret.piatt@rackspace.com>
Subject: Re: get_field_str() and interpret_field() bug with multi-word fields
Date: Wed, 13 Aug 2008 14:49:12 -0400	[thread overview]
Message-ID: <48A32CA8.5060800@hp.com> (raw)
In-Reply-To: <200808131302.05804.sgrubb@redhat.com>

Steve Grubb wrote:
> On Wednesday 13 August 2008 12:25:09 Klaus Heinrich Kiwi wrote:
>> I like Mathew's idea of having a binary format though. Maybe it's
>> possible to carry the legacy format for some time while we have a more
>> robust (and extensible) binary format in parallel? And then having a
>> binary format version tag within each record?
> 
> Yes, there would have to be a migration path. I think we talked about XDR as a 
> possibility 4 years ago because its already inside the kernel. The kernel 
> guys at the time wanted to re-use something already inside or something that 
> was compact in its representation.
> 
> What I believe lead to text based was the general feeling that logs should be 
> human readable with less, tail, or vi if need be.

LAuS had a binary record format and I don't recall people complaining
about it.

> A problem with binary representations will be what happens with aggregated 
> big-endian and little-endian system logs?

Just define a standard.

> 
>> I know I know, at the time I have more questions than answers. I only
>> wanted to express my feeling that there is indeed a problem with the
>> current format.
> 
> There is a problem with any format. How would changing to binary help when we 
> realize that we forgot auid in CONFIG_CHANGE? The only thing that might help 
> is to stab a version number into each record because its size is going to 
> change. This is going to lead to much more complex code in the parser.
> 
> The current technique is flexible in that the field is either there or not but 
> it parses either way. For example, we recently added ses to syscall records. 
> The auparse library can handle it being there or not. Now and in the future. 
> The application that uses those logs may have to decide whether that's 
> important or not. I don't think that is a judgment call for a library to 
> make.
> 
> In a binary representation, you would have a version number to describe what 
> structure to cast the pointer to. If you have new log with old user space, it 
> won't parse because it won't have the template to cast with.

Is that any different from not being able to parse something the tools 
don't know about?

-- ljk
> 
> 
>> I know you and Steve tried before to talk with the SELinux guys trying
>> to have a saner format for AVCs and stuff. Do you feel that's an
>> impossible barrier to cross or maybe we try again and convince them that
>> stricter formatting rules will bring more users for their audit data?
> 
> I don't know their recent thoughts on this. USER_AVC is seriously broken and 
> unusable. I've been thinking about linking auparse to sending user space 
> events to make sure that only parsable events are sent (it would go to syslog 
> with an error so that its not lost forever). No app should consider sending 
> an event as a performance impact, so this should be doable - but not in the 
> 1.7.x seres.  :)
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit