[RFC] upstreaming audit filesystem pieces

[Amy Griffis]

Hello,

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.

Audit Requirements
------------------
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
  location.

- 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
  created files.

Suggested Approach
------------------
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
  were met.

- 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
  occurs.

- 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
processing.

Information collected from the getname() and path_lookup() hooks is
stored in the audit_context's names[] list, and is logged as
AUDIT_PATH records.

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
consolidation possibilities.

Regards,
Amy