[RFC][PATCH] (#4) auditfs

[Timothy R. Chavez]

On Wed, 23 Feb 2005 13:58:57 -0600, Klaus Weidner <klaus at atsec.com> wrote:
> On Tue, Feb 22, 2005 at 01:58:42PM -0600, Timothy R. Chavez wrote:
> > 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?
> 
> read() and write() aren't considered security relevant operations since
> they don't do any permission checks. From the CC point of view the
> interesting call is open(), and if that's properly handled it's enough.
> 
> In most real-world scenarios you probably won't want to be auditing read
> and write operations individually anyway.
> 
> > 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?
> 
> The only CAPP requirement is to record success/failure, you'll actually
> get a bit more if you audit the errno as reported by the kernel, that way
> permission failures should get EACCES as opposed to ENOENT or other error
> conditions.
> 
> -Klaus
> 

Ok, great.  I've removed the hooks.  I can also get away with taking
the hooks out of unlink right because I should be hitting permission()
in access(), before I do the unlink()?
-- 
- Timothy R. Chavez