[RFC][PATCH] (#4) auditfs

[Timothy R. Chavez]

On Tue, 22 Feb 2005 13:24:34 -0500, Stephen Smalley <sds at tycho.nsa.gov> wrote:
> On Tue, 2005-02-22 at 10:42 -0600, Timothy R. Chavez wrote:
> > - Hooks in vfs_read/write/unlink (please look closely here).  The rule
> > of thumb I went off of is: I can call my hook iff I have an inode and
> > I'm NOT hooking lookup_hash *nudge Stephen* :)
> <snip>
> > Three hooks for dynamically assigning watches:
> > d_splice_alias, d_move, d_instantiate
> >
> > Five hooks for dynamically adding watches to our context:
> > permission, exec_permission_lite, vfs_read, vfs_write, vfs_unlink
> 
> Why do you hook vfs_read/vfs_write when you have a hook in permission?
> If you are trying to audit actual reads and writes, then there are other
> cases to consider, e.g. do_sendfile(), plus fun with AIO.  Much easier
> if you can just stay with auditing open(2) calls via your permission(9)
> hook.

I've only done this because I was under the assumption that every
syscall that can access a watched file system object in some fashion
should be able to generate records.  I see what you're saying though,
Stephen.  And admitedly,  I am also being a little redundant in that
the original code can already provide us with the read() and write()
exit code and the file/directory being read from/written to.  However,
if we want to specifically monitor activity in the filesystem
surrounding watched objects, then wouldn't these hooks in read(),
write(), etc be vital?  Klaus?  How else will we know if a read() or
write() trully succeeded or failed on a watched filesystem object?

If we just rely on the open(), however, we cut out the read/write
hooks, plus whatever else would need be added.

Perhaps there's enough information in just an open().  The record will
give us the filesystem object information, plus it will tell us which
permission was used (READ/WRITE/EXEC/APPEND) provided it allows for
that permission in the mask and the exit code of the open().  However,
will the exit code necessarily be a reflection of a permission
failure?
  
> 
> There is a known race with respect to d_instantiate and file creation,
> but it needs to be resolved anyway for SELinux, so I think you can
> proceed under the assumption that it will be fixed.  Alternatively, you
> would need to move your hook call prior to the setting of d_inode in the
> dentry and pass in the inode separately to your hook.
> 

Ah yes, I remembering you talking about this earlier.  I'll keep this
in mind and work under the assumption that this will be fixed for the
time being.

> --
> Stephen Smalley <sds at tycho.nsa.gov>
> National Security Agency
> 
> 


-- 
- Timothy R. Chavez