best way to audit in vfs

[Timothy R. Chavez]

hm "never overwritten ever" :-) all this holiday cheer is having
adverse effects on me.

On Wed, 15 Dec 2004 17:03:35 +0000, Timothy R. Chavez <chavezt at gmail.com> wrote:
> On Wed, 15 Dec 2004 11:01:49 -0500, Stephen Smalley <sds at epoch.ncsc.mil> wrote:
> > On Tue, 2004-12-14 at 16:22, Stephen Smalley wrote:
> > > Yes, but why can't you make the full determination in your hook
> > > function?  At the point of the hook function, you know:
> > > - the current process information,
> > > - the object information,
> > > - the call site.
> > >
> > > It is possible that you have some complex audit configuration in mind
> > > that requires tying together information from multiple hooks in order to
> > > determine whether or not to audit the operation, but I'm not sure
> > > whether that is necessary.
> >
> > On the other hand, it may be that by simply saving the object identity
> > information on a list in the current audit_context and deferring
> > determination to the syscall exit code, you can reduce the number of
> > audit hooks within the VFS, e.g. just hook permission(9) rather than the
> > individual vfs_* functions.
> 
> That seems like a pretty good idea since all the information about the
> syscall will be covered else where, all we really need is a place
> where we have the inode and access to its audit data.  The two places
> (maybe three? vfs_mknod?) vfs_create and vfs_mkdir (vfs_link wouldn't
> be necessary if we assume a hardlink's inode audit information is
> never overwritten ever)
> 
> What this means is we can add some additional (minimal) filtering
> rules to the kernel for our file system objects.
> 
> Are there any objections with this approach?
> 
> >
> > --
> > Stephen Smalley <sds at epoch.ncsc.mil>
> > National Security Agency
> >
> > --
> > Linux-audit mailing list
> > Linux-audit at redhat.com
> > http://www.redhat.com/mailman/listinfo/linux-audit
> >
> 
> 
> --
> - Timothy R. Chavez
> 


-- 
- Timothy R. Chavez