Re: audit.20 kernel
On Monday 11 April 2005 19:27, Stephen Smalley wrote:
<snip>
Also, as I've seen no response to the auditfs rfc/patch on
linux-
fsdevel, I'd suggest updating the patches and taking them to linux-
kernel, with explicit cc'ing of particular individuals whose feedback is
especially desired (e.g. viro, akpm, feel free to suggest others) and
explicit cc'ing of individuals from this list who want to be involved in
any discussion (e.g. me, dwmw2?, chrisw?, feel free to suggest others).
But I think that this also requires getting the other patches on which
the auditfs patch depends re-based to the latest -mm and posted to
linux-kernel.
Yeah, I finished work up on the user space/kernel space transport feature
(separated the kernel/user audit_watch structure, added a transport structure
per Stephen's suggestions, etc) and completed a basic watch listing feature,
which will return to user space a list of all watches. If at the time of the
listing, the watch's parent could be reached, its returned as a "valid"
path,
otherwise it's returned as an "invalid" path. The last bit of information
that needs to be added and finalized before I submit is a new field on the
watch for "device", so when a list is sent back to user space you can tell
the difference between the watch "/tmp/foo" and "/tmp/foo" ;-)
Granted, this
is probably a little over board as far as a CAPP certification is concerned,
but I figure it's generally useful; can't hurt.
I'm also a little concerned about how the administrator is going to be able to
_effectively_, _realistically_, and _intuitively_ interpret what they're
seeing in the audit log with regards to file system auditing. This is mostly
due to the possibility of a single syscall generating multiple records. Even
I have to double check the hook placement to make complete sense of all the
records being generated. When we document expected results they should be
perfectly explainable, wouldn't you agree? So, perhaps some kind of flagging
that's human readable in the audit record (ie: CREATE_*, UNLINK, RENAME_TO,
RENAME_FROM, PERMISSION, etc) would prove useful.
Perhaps something we can talk about tomorrow.
-tim