audit.20 kernel

[Timothy R. Chavez]

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