From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Matteo Michelini" Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Fri, 15 Aug 2008 15:58:54 +0200 Message-ID: <87ba673d0808150658v7ce2f764s72b517c9dedfc4b6@mail.gmail.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <48A1EB72.6070607@redhat.com> <1218571902.3540.2.camel@localhost.localdomain> <200808121632.55341.sgrubb@redhat.com> <1218587598.3437.23.camel@klausk.br.ibm.com.br.ibm.com> <1218640141.3540.38.camel@localhost.localdomain> <1218644709.8857.10.camel@klausk.br.ibm.com.br.ibm.com> <1218738325.29535.85.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m7FDx6tW005087 for ; Fri, 15 Aug 2008 09:59:06 -0400 Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m7FDws4M030246 for ; Fri, 15 Aug 2008 09:58:55 -0400 Received: by yx-out-2324.google.com with SMTP id 31so583747yxl.81 for ; Fri, 15 Aug 2008 06:58:54 -0700 (PDT) In-Reply-To: <1218738325.29535.85.camel@moss-spartans.epoch.ncsc.mil> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Stephen Smalley Cc: linux-audit@redhat.com, Bret Piatt List-Id: linux-audit@redhat.com I'm working on a binary format for the linux-audit system as part of a university research project. The goal is having something similar to BSM trails. What do you think about it? 2008/8/14, Stephen Smalley : > > On Wed, 2008-08-13 at 13:25 -0300, Klaus Heinrich Kiwi wrote: >> On Wed, 2008-08-13 at 11:09 -0400, Eric Paris wrote: >> > 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. >> >> That's exactly my point. There's no sense in discussing a 'ideal' format >> for audit stream coming out of the kernel, since it's well agreed >> (thankfully) that the kernel part should be as minimal as possible. >> >> 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? >> >> 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. >> >> 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? > > If you want to ask the "SELinux guys", ask on the selinux@tycho.nsa.gov > list. But in this case: we've always been willing to take changes to > the AVC audit format; we have merely pointed out that it has to be done > in a way that provides full backward compatibility both in kernel and in > the userland, as we are not allowed to break existing userland with new > kernel and we'd like new userland to still work on old kernels. Patches > that meet those standards accepted. > > -- > Stephen Smalley > National Security Agency > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > -- Matteo Michelini (Milan - Italy) http://www.michelini.co.uk Linux registered user: #332873