best way to audit in vfs

[Klaus Weidner]

On Tue, Dec 14, 2004 at 03:03:08PM -0500, Stephen Smalley wrote:
> On Tue, 2004-12-14 at 15:00, Timothy R. Chavez wrote:
> > I've been kind of thinking about this.  Presumably, we want to audit
> > both failed and successful attempts in whatever vfs function we happen
> > to be in.  For instance, if we fall out of vfs_mkdir because
> > may_create returned an error, we'd like to receive an audit message
> > that said something like, "filename=myfile syscall= mkdir()
> > error=<errno>.....", but, would I want to do this by hooking each
> > conditional statement?  Is there a better approach?  The only other
> > one I can think of would be to have one exit point in the functions
> > and audit right before we exit...
> 
> The audit framework already lets you audit on syscall exit, which lets
> you capture information like this.  As I understand it, you don't need
> additional hooks for that purpose, just for enabling auditing based on
> object identity and for propagating audit attributes on objects.

Agreed, the existing LAF approach of intercepting system calls could
remain unchanged:

- system call is entered, audit intercept notes that it's of potential
  interest to audit (i.e. due to filter rules being configured for
  open()). Syscall arguments passed directly in registers are directly
  available (i.e. SYSV SHM IDs), but the audit code does not attempt to
  retrieve anything that is passed indirectly via userspace pointers.

- while system call is executing, additional information is collected
  based on the data copied from userspace by the syscall. In the case of
  filesystem operation, this would be the audit attribute associated with
  the inode being worked on.

- when the system call is complete, the filter rules are applied to the
  available data (including the additional info), and an audit record
  is generated and sent to userspace.

The role of the VFS hooks is simply to ensure that objects in the
filesystem have the audit attribute set correctly even when they get
moved around and created in the filesystem. It essentially adds the
necessary logic to handle the position-based audit requirements that the
LAF inode-based approach can't do directly.

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.

-Klaus