[RFC][PATCH] (#4) auditfs

[Klaus Weidner]

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