best way to audit in vfs

[Leigh Purdie]

On Tue, 2004-12-14 at 16:58 -0600, Klaus Weidner wrote:
> On Wed, Dec 15, 2004 at 09:29:05AM +1100, Leigh Purdie wrote:
> > If you store audit attributes as a real file-system attribute:
> > * You're unlikely to be able to audit files on non-native filesystems
> > (eg: VFAT, CDROM, or USBKeys) - one audit objective that is very popular
> > in intelligence circles, for example, is "What has been copied out to
> > removable media?"
> 
> Note that it would be fairly easy to do all-or-nothing audit for
> non-native filesystems based on the properties of the mount point or
> filesystem type, so the removable media example is not necessarily a
> problem if treated as a special case.

Good point. I have come across instances though, where it is important
to monitor non-native file systems. All-or-nothing works up to a point,
but falls over when the volume of file accesses is very large.

An example might be where a solaris box acts as a SAN/NAS, mounted over
NFS - but the users wants to make use of the linux audit subsystem to
monitor a subset of that file system.

Two options:
* Auditing is the responsibility of the host operating system (ie: Let
sun take care of it), or
* There needs to be some way of flagging only some files for audit
analysis.

I'm not sure I advocate either approach at this point.. but it certainly
factors into the decision for/against on-file-system attributes. :)

> > If you retain a 'virtual' attribute within the audit subsystem:
> > * Your CPU usage increases, as you have to go through the full inode ->
> > real path chain to form a full directory path, before comparing the
> > directory path against the user's filters. (eg: "Tell me whenever
> > someone writes a file to /media/usbkey/.*")
> 
> Your suggestion is based on the audit system storing paths as the virtual
> attributes, and using these for comparisons.

True.

> One approach we had also been discussing had been to attach the
> properties to in-memory dentry or inode objects for individual files and
> directores, in essence an in-memory overlay of additional attributes over
> the existing file tree. This is of course only feasible if the number of
> objects with individual audit attributes is small enough to not use too
> much memory.

True. This might actually be very appropriate for a simple 'tell me
stuff that has changed in /etc' sort-of-configuration, which would be
fine for quite a few sites.

The more complex: "Audit every file in /data, and tell me whether the
user X,Y, or Z access any file successfully with a directory path
containing the word 'SECRETSTUFF'", might be a bit more challenging to
implement, particularly if there are hundreds and thousands of files in
such directories. (This is a real-world example/requirement by the way..
with a few details changed, obviously :)

The kernel/userspace split on that objective might be along the lines
of:
kernel: Audit all files in /data for READ or WRITE, success.
userspace: check if filename contains "/SECRETSTUFF/", and is accessed
by user X, Y or Z.

L.