From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linda Knippers Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Wed, 13 Aug 2008 14:49:12 -0400 Message-ID: <48A32CA8.5060800@hp.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <1218640141.3540.38.camel@localhost.localdomain> <1218644709.8857.10.camel@klausk.br.ibm.com.br.ibm.com> <200808131302.05804.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200808131302.05804.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: William Kelly , linux-audit@redhat.com, Bret Piatt List-Id: linux-audit@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