[PATCH 2/2] Audit: remove the limit on execve arguments when audit is running

[Linda Knippers]

Steve Grubb wrote:
> 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.

But for any given system call, wouldn't you always get the same number
of PATH records?

I think its important to know how many of the argument records are
expected, which I think would applies to both the number of arguments
as well as the number of records for any particular argument.

With PATH records, there's an item count in the SYSCALL record and
each PATH record says which one it is, so its possible to verify that
you've gotten them all.  I don't see the same type of information for
the arguments so its not possible to know if you've got a complete
audit trail.
> 
>> 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.

Our tests do their own parsing and I expect we'll continue to do that.

-- ljk

> 
> 
>> 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
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit