[RFC][PATCH] Prelim in-kernel file system auditing support (resent)

[note] I'm impatient. The patch is ~25KB and did not seem to go through to the list the first time, so I've resent the e-mail with a URL instead: Download: http://www.busy-wait.com/linux-2.6.10-auditfs-tc1.patch [/note] Hello, Attached to this e-mail is my first iteration of the file system auditing piece needed for CAPP EAL4. I appreciate all feedback, but please read the TODO list prior to sending me feedback on something I'm already aware of. I've not stressed tested this code nor have I done any formal FVT. The testing I have done has been.. minimal. I've mostly seen if given scenarios work (move one watched file to another watched location, create a hardlink to /etc/passwd from /home/me, etc). At this time, I'm unable to provide you with the userspace patch I wrote, but encourage someone on this list to add the functionality to libaudit/auditctl and submit the patch (Steve :)?). If you'd like my "guidance" please e-mail me privately. ABOUT: Thus far, the patch being submitted with this e-mail implements a rudimentary file system auditing capability using the in-kernel audit subsystem. From userspace, an administrator passes into the kernel a pathname and filterkey pair. The terminating file or directory does not have to exist at the time a watch point is created for it, but it's parent does. If at any point the parent is destroyed, auditing information for its children is lost. Likewise, if we mount over watched paths, we lose auditing information, until we unmount. Currently, there is no decision on whether or not we ought to give the audit subsystem the capability of dynamically remapping watch paths onto new mounts or supporting theoretical watch paths where watch paths are arbitrary and if they should come into existence within the filesystem, they become watched and thus auditable. Also, if I remember my code correctly, if you move out of a watch path into a path that is not being watched, your watch field is still pointing in a watch list, and will be audited. If you destroy this file or directory and recreate it in the same (unwatched) path, it will no longer be audited. I think I need to add a field to the watch where we can enable/disable this behavior per watch entry. Provided both syscall auditing and file system auditing are both configured and enabled, when a syscall of interest accesses a file or directory being watched, it collects information about that file or directory (via it's inode and watch entry) and adds it to the audit_context of that syscall. When the syscall exits, any files or directory information collected is sent to userspace to be logged. TODOs: * Add RCU locking in the appropriate places to make SMP-safe * Switch over to slab caches for struct audit_data, struct audit_file, and struct audit_watch * Think about how I can make it so an administrator can say, "Watch this file only on the syscall open where uid=0" -- As of right now, if filesystem auditing is on, every syscall (being audited) that accesses a watched file or directory collects information about it and generates a record. Is this sufficient? * Make it so filesystem auditing can be dynamically enabled/disabled from userspace, rather then being "enabled" if configured or "disabled" if not configured at boot time. * Add/remove unnecessary information about the file or directory being collected in the audit context. Input on this? -- - Timothy R. Chavez