[Date Prev][Date Next] [Thread Prev][Thread Next]
[RFC] upstreaming audit filesystem pieces
- From: Amy Griffis <amy griffis hp com>
- To: linux-audit redhat com
- Cc: John McCutchan <ttb tentacle dhs org>, Robert Love <rlove rlove org>
- Subject: [RFC] upstreaming audit filesystem pieces
- Date: Tue, 23 Aug 2005 16:36:02 -0400
A few weeks ago I posted some mail stating my concern for the
direction being taken to try to get audit's additional filesystem
pieces upstream. I've done some research into other possible
approaches and thought I'd post some thoughts.
First, here is my understanding of how the upstream audit code must be
augmented to meet CAPP requirements, which are the baseline
requirements for audit.
- Provide the capability to specify filters for non-existent
files/directories, provided their parent directory exists. Filters
must take effect when a file/directory is created at the specific
- Provide persistence for filters specified with a given pathname,
given the existence of the parent directory. Filters must be
applied to all filesystem events happening at said pathname.
- Provide additional filesystem information not captured by the
getname() and path_lookup() hooks, e.g. inode information for
The plan proposed several weeks ago was to write a general filesystem
event notification component for the kernel, based on the current
auditfs patch. I think this is a mistake for several reasons.
- The auditfs patch was not designed to be used by multiple clients.
- The locking performance is relatively untested, and was not designed
for multi-client use.
- The auditfs patch was designed to meet the specific needs of audit
and may not meet the needs of other consumers. We would need to go
through some requirements discussions to ensure any consumers needs
- The desired functionality is essentially already there in Inotify.
Inotify is designed to be used by multiple clients, has clean locking,
and has undergone quite a bit of testing and performance work. It
already does most of what audit needs. It provides the capability to
watch a parent directory for file or link creations, renames, and
removals. It also provides events for attribute changes. I believe
audit's remaining requirements on Inotify are few.
In order for audit to use Inotify, Inotify would need to provide:
- An Inotify kernel API.
- A pointer to the relevant inode struct when a filesystem event
- The ability to begin watching a file at the moment of creation.
Currently audit is pre-notified, via dcache hooks, when a file is
created, moved, or deleted. This allows audit to enable or disable
a watch on the appropriate inode. Audit would need a similar
pre-notification, or preferably the ability to add (and possibly
remove) watches from an Inotify event callback.
- Possible changes to fsnotify hook placement to ensure that the
information recorded by audit (inode, filename) is correct.
- Possible additional filesystem events correlating with some of the
events currently obtained from audit's catch-all hooks in
permission() and exec_permission_lite().
In order for audit to use Inotify, audit would need to:
- Create an Inotify watch on the inode of any existing file/directory
specified in audit filters.
- Create a corresponding Inotify watch on the parent directory of any
file/directory specified in audit filters. This watch may only need
to exist when the specified file/directory doesn't exist.
- Provide an event callback which would perform the necessary actions
for various filesystem events. This would involve updating the
audit_context and adding (and possibly removing) Inotify watches.
- When watched inodes go away, Inotify automatically removes any
relevant watches and generates a removal event(s). Upon receiving
the removal event, audit would log an 'implicit removal' record.
Progress & Next Steps
A couple weeks ago I wrote a patch that provides a basic Inotify
kernel API, as a proof of concept. I'm sending that patch in a
follow-up email. I also sent it to John McCutchan (cc'd) for
feedback. He has been supportive of the effort, but would like us to
tighten audit's requirements so he can determine if the necessary
changes would make sense for Inotify.
I've also been working on understanding audit's specific needs
regarding VFS hook placement. I would like to discuss this some more
to determine whether this approach is indeed viable. John (and
Robert), please let us know if you would like to be party to these
converations, or if you would prefer we send you a summary.
Other Things to Consider
Any approach to getting the audit filesystem pieces upstream will
require some changes to the current implementation. I think this
would be a good opportunity to do some data structure consolidation.
Filesystem data collected by the auditfs filesystem hooks is not
integrated with other filesystem data collected during system call
Information collected from the getname() and path_lookup() hooks is
stored in the audit_context's names list, and is logged as
Information collected by hooks in namei.c, attr.c, and xattr.c is
stored in auxiliary audit_aux_data_watched structures and is logged as
AUDIT_FS_INODE and AUDIT_FS_WATCH records.
These pieces of information are never tied together other than by
having the same audit record serial number. I don't see any reason
why this needs to be the case. At the very least, combining these two
parts of syscall processing would result in more readable audit records.
Thanks for taking the time to read this email. I would appreciate
any comments on both the Inotify approach and the data structure
[Date Prev][Date Next] [Thread Prev][Thread Next]