[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: best way to audit in vfs



On Tue, 2004-12-14 at 22:44 +0000, Timothy R. Chavez wrote:
> Because we're storing
> information on the parent node, the file or directory to be audited
> does not have to exist, but when it does exist, it will get audited. 

*VERY* Good point.
A good example of this sort of thing might be an objective that says:
"Tell me whenever someone attempts to write to /etc/hosts.equiv".
There may not be an actual /etc/hosts.equiv on your file system, but the
system administrator will definitely want to know if someone attempts to
create that file.

> Perhaps the mapnode tree (which basically lays out a "theoretical"
> flat file system tree in memory and maps into inodes that represent
> each position in that tree) would be a nice feature to add, but is not
> completely necessary at this point, to achieve the functionality we'd
> like.  It might be really hard to push and could slow down progress
> towards an upstream solution.

Agree. If we can find a nice low-CPU cost way of converting an Inode to
a path, and filtering on that basis, it would be very handy.

In snare, we do this by either:
* Grabbing the path of the inode (if available), or 
* Saving off the path provided to the system call (eg: ../../blah), plus
the current process vfsroot (eg: /etc/security).
We send both these paths to userspace, and do a custom realpath() on
them (/blah). Not an ideal solution, but a minimally invasive one for
the kernel. It also means that all path filtering has to be done in
userspace, which means a lot of (potentially unnecessary) kernel-
>userspace comms. 

L.
-- 
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]