[PATCH 2/2] Audit: remove the limit on execve arguments when audit is running
Linda Knippers
linda.knippers at hp.com
Tue Oct 9 02:34:44 UTC 2007
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
More information about the Linux-audit
mailing list