Re: best way to audit in vfs
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/