From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH 2/2] Audit: remove the limit on execve arguments when audit is running Date: Mon, 8 Oct 2007 17:41:41 -0400 Message-ID: <200710081741.42819.sgrubb@redhat.com> References: <1191360589.9506.34.camel@localhost.localdomain> <1191597087.3198.7.camel@dhcp231-215.rdu.redhat.com> <20071008194557.GA32746@w-m-p.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20071008194557.GA32746@w-m-p.com> 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: linux-audit@redhat.com Cc: a.p.zijlstra@chello.nl List-Id: linux-audit@redhat.com On Monday 08 October 2007 15:45:57 Klaus Weidner wrote: > On Fri, Oct 05, 2007 at 11:11:27AM -0400, Eric Paris wrote: > > My belief is that the solution to this problem is to allow audit to > > break individual arguments down to a size <8k. I guess my syntax would > > be something like > > > > a0[0]=(first 8k of a single huge argument) > > a0[1]=(second 8k of a single huge argument) > > [...] > > > who has a problem with that syntax? will userspace puke? > > I'm a bit worried about special audit record formats that aren't > generally seen in normal operation, since that's an obstacle to > testability. Well, I take this one to be the same as PATH records. Sometimes you get 1, sometimes 2, sometimes 3. > The ASCII audit format encourages an ad-hoc parsing approach, and it's > likely that tools other than the shipped ones won't be able to handle this > and will break unexpectedly, possibly offering avenues to hide events with > unusual records. (I know that people are supposed to use the parsing > library, but they aren't being forced to.) I also doubt people doing adhoc parsing know the encoding scheme either. So, they will hit a problem sooner or later. > Would there be a clean way to handle this kind of reassembly in auditd to > ensure that the on-disk record will continue to be in the currently > documented format? Well, the record size limit affects realtime interface programs too. They would all need to be recompiled to handle a bigger record. > Or is there a way to strongly encourage people to keep their hands off the > raw audit logs and use documented interfaces that take care of the > conversions? I suppose I could add a note to the daemon's man page. SE Linux has given the logs a special type and as long as you are not in an unconfined domain, you shouldn't be able to access it. -Steve