Re: best way to audit in vfs
On Wed, 15 Dec 2004 11:01:49 -0500, Stephen Smalley <sds(a)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(a)epoch.ncsc.mil>
National Security Agency
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
- Timothy R. Chavez