Messages in this thread | | | Date | Fri, 10 Dec 2004 16:35:10 +0000 | From | Timothy Chavez <> | Subject | Re: [audit] Upstream solution for auditing file system objects |
| |
On Fri, 10 Dec 2004 09:29:18 -0500, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote: > On Fri, 10 Dec 2004 00:02:31 GMT, Timothy Chavez said: > > > Over the last two months, I've been given the daunting task of > > implementing a feature by which an administrator can specify from user > > space, a list of file system objects (namely regular files and > > directories) that he/she wishes to audit. > > One *big* question that you don't address at all in your mail: > > Do you need *real time* tracking of changes/etc, in which case inotify or > something based on it are probably an approach to follow (note that I don't > think inotify currently deals with read-only access to a file). > > Or do you not care about real-time tracking, but have a requirement to be > able to go back and say "Oh, at 9:03:38.99342 last Tuesday, user XYZ > tried to open this file" - if that's what you want, you probably want to > look at the audit subsystem and its support for syscall auditing. > Valdis,
Thank you for the reply. There is no need for real-time tracking to meet this requirement. You have the right idea with the timestamped message.
And yes, the audit subsystem that's in existence now is something we want to work with and improve. Like I had mentioned earlier, it could just be a matter of logging the VFS relevant portion ("this <file/directory> was accessed / altered by") with the same serial number as the syscall ("open() called under these <conditions>") and then piecing the entire audit record together in userspace and filter it accordingly.
The main goal here is to not be redundant and make use of our resources. I personally like Robert's idea with the general hooking framework. Making the audit subsystem, itself, modular also sounds like a pretty good idea.
Thanks again!
-- - Timothy R. Chavez - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |