Re: best way to audit in vfs
I think its reasonable enough to keep it virtual. The added benefit
to doing it this way is we no longer need the mapnode data structure.
We assume that all files and directories to be audited complete paths
that already exist in the file system. 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.
If the parent directory is destroyed and then recreated, there's no
way to for it to regain knowledge of what its suppose to be watching
or if its on the path to something that needs to be watched. There
are disadvantages to not supporting this, but for simplicities sake,
someone could simply restart auditd or whatever to remap the changes.
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.
On Wed, 15 Dec 2004 09:29:05 +1100, Leigh Purdie
<Leigh.Purdie(a)intersectalliance.com> wrote:
On Tue, 2004-12-14 at 14:31 -0600, Klaus Weidner wrote:
> It's still open if the audit attribute is a real extended attribute
> stored on disk, or if it's virtual and exists only in the audit VFS
> layer. Storing them on disk makes it automatically persistent, while the
> virtual approach requires the admin to keep a separate audit config list
> up to date and reload it on boot.
There are advantages and disadvantages to both approaches.
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?"
* Audit object inheritance can become VERY complex:
- When a new file is created in an audited directory, we have to ensure
that the parent directories audit attributes are applied immediately,
and the actual 'create/open' audit events associated with the created
file are also retrospectively created. (Windows NT had real problems
with this. Windows 2000 seems to have come up with something relatively
reasonable).
* Wildcard matching of file accesses becomes pretty-much impossible.
- A sample objective might be "Tell me whenever someone accesses a file
within a directory called 'SECRET_FILES'"
* On the positive side, your CPU usage is likely to be significantly
less, as the audit layer just needs to check for an 'auditing enabled'
flag before deciding whether to exit, or continue processing.
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/.*")
* You can do wildcard (or regular expression) matching on target files,
which is VERY useful.
* File system type is pretty-much irrelevant.
* Object inheritance in the file system is not a concern.
Summary of operating system implementations:
Windows NT / 2000 / XP / 2003: On-file-system attribute.
Solaris / AIX / Irix / Snare: Virtual.
Regards,
Leigh.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
- Timothy R. Chavez