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

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.

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

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

> 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(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit