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

[Steve Grubb]

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.

> 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.

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.

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.

-Steve