get_field_str() and interpret_field() bug with multi-word fields
Linda Knippers
linda.knippers at hp.com
Wed Aug 13 18:49:12 UTC 2008
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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
More information about the Linux-audit
mailing list