Re: best way to audit in vfs
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.