Re: [audit] Upstream solution for auditing file system objects

[Timothy Chavez]

On Fri, 10 Dec 2004 09:29:18 -0500, Valdis.Kletnieks@xxxxxx
<Valdis.Kletnieks@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/