best way to audit in vfs

[Leigh Purdie]

On Tue, 2004-12-14 at 16:06 -0500, Stephen Smalley wrote:
> Another point to keep in mind is that you ultimately want to instrument
> other subsystems in the same manner as the filesystem code to capture
> relevant information copied by the kernel from userspace pointers (e.g.
> socket addresses), and I doubt you want to keep adding all of this
> object identification information into the current audit context (and
> there can be mixing, e.g Unix domain socket interplay with the
> filesystem, so you might need object identification information for
> multiple kinds of objects on a single syscall).

Just as an addendum to Stephen's comments:

There are generally few items-of-interest to a system auditor associated
with a system call.

For most system calls, the auditor wants to know: Who, when, what, and
success.
* The 'who' breaks down to EUID/EGID (and sometimes RUID/RGID).
* The 'when' is a local timestamp down to seconds (milliseconds are only
important if the audit subsystem can potentially report events out of
'sequence'.
* The 'what' is system call dependent, but is usually one or two key
items.
- For execve, the binary (with path), and arguments.
- For file opens, the filename, and open flags (generally, broken down
to either 'read' or 'write').
- For renames, the source and destination paths.
- For 'accepts', the source IP and the destination port.
- For 'connects', the destination IP and the destination port.
* The 'success' is whether the system call failed or succeeded.

I guess what I'm saying, is that you shouldn't need to go overboard,
trying to store every single attribute of a particular system call -
there are only a few that are going to be of interest to an auditor at
the end of the day.

Additional details are great for debugging... but leave that to strace
to cover. :)

Leigh.
-- 
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/