Re: [PATCH 2/2] Audit: remove the limit on execve arguments when audit is running
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