VFS hooks analysis (pass 1)

[Amy Griffis]

On Tue, Aug 30, 2005 at 04:36:25PM -0400, Amy Griffis wrote:
> On Mon, Aug 29, 2005 at 05:12:01PM -0500, Timothy R. Chavez wrote:
> > Here's my thinking.  It'd be nice to have a complete set of Inotify hooks
> > that map to specific Inotify events (IN_*).  Thus, even though the above
> > syscalls may be sufficiently covered by the hook placements in the 
> > getname() and path_lookup() functions, I think we should split them out
> > into seperate Inotify hooks.  
> 
> Thanks for the input, Tim.  I'll look into this.

Here's what I found.

CAPP specifies that audit must capture unsuccessful attempts for some
events.  I believe the set is limited to the open, rename, truncate
and unlink syscalls.  Could someone verify that?

Inotify doesn't provide events for attempted operations.  Using
getname/path_lookup hooks plus Inotify, we lack information for rename
and unlink attempts.  Without getname/path_lookup, we lack information
for open and truncate attempts as well.  This is not a serious
setback, we were going to have to address the attempted operations
issue anyway.

It is interesting to note that replacing the getname/path_lookup hooks
creates some changes in the potential for race conditions.  The
information collected by getname/path_lookup always corresponds to the
filesytem objects referenced by the syscall args.  The placement of
some of the fsnotify hooks leaves room for races where the event
information might change before the hook is called.  With
getname/path_lookup, the information collected could be mismatched;
without them, it could be completely wrong.  Either way, this is a
problem, so replacing getname/path_lookup shouldn't be a factor here.
I expect that the Inotify maintainers will be interested in removing
the race conditions, so I don't consider it a showstopper.  I'll
explain the race conditions more completely in a follow-up email.

The most significant issue is that these syscalls don't generate
Inotify events.

    sys_access
    sys_chdir
    sys_execve
    sys_swapon
    sys_mount

The target pathname(s) would be available from the syscall args in the
audit logs.  However, we would not be able to do any filename or
inode-based filtering for these syscalls without additional Inotify
events or audit-specific hooks.  This may be acceptable for some of
the listed syscalls, but we have been using this feature in the sample
CAPP config to flag executions of the stunnel program.

Are filename or inode-based filters required for each of these five
system calls?  Comments anyone?

Thanks,
Amy