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

[Linda Knippers <linda.knippers@hp.com>]

Steve Grubb wrote:
> On Monday 08 October 2007 18:45:15 Linda Knippers wrote:
>>> 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?
> 
> Maybe, sometimes you get a socket address record, too/instead of. The point is 
> that you have no idea how many of them you are going to get without some 
> analysis.

In the case of arguments, don't you know argc?  You could emit argc= before
a0.

>> 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. 
> 
> The way these get split, there is no way to know ahead of time how many you 
> are going to get.  These are being split as they are being output. The item 
> count displayed in syscall is incremented as each aux record data is added to 
> the context. So, there's no performance cost for displaying this.

I care about knowing how many arguments there are so that I know if I've got
them all, not so much how many records get emitted.  However, in the case
where a single argument is split across multiple records, I think it would
be good to know that I've gotten 1 of 3, 2 of 3, 3 of 3, etc, or the total
length of the argument.
> 
> We could add an item parameter, but that only gives you sequence information. 
> But you could infer the sequence information by the argument's number - it 
> continually increments. If a record ends and a347 and the next one begins at 
> a895, then you are missing one or more records.

Unless I'm missing the last records for a syscall, in which case all I know
is that there aren't any more in the log.
> 
> But even then, I don't think that's possible unless someone's tampered with 
> the logs. If any allocation can't be done, the syscall is failed. So, the 
> only question is what happens if the netlink queue has a problem sending to 
> user space? Well, you get a syslog message and the kernel follows the  
> failure action set by the admin - just as it would for any event.
> 
>> 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.
> 
> When it moves on to another record type, you've got them all.

Not necessarily.

-- ljk
> 
> -Steve