VFS hooks analysis (pass 1)

[Amy Griffis]

On Thu, Sep 08, 2005 at 11:34:21AM -0500, Timothy R. Chavez wrote:
> > 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.
> 
> Even though CAPP possibly limits us to this set (what about syscalls that
> alter meta data like: chown, chmod, and setxattr?), I think we should be
> both:
> 
> 1) Consistent.  Any system call that operates on an inode such that it
> has the potential of altering that inode should be audited as early as
> possible.  This not only keeps the hook-set "symmetric", but prevents
> us from dropping out before we can add the watch to the audit_context.

Are you suggesting pre and post hooks for all the filesystem
operations?

> The downside to this is that there may be extra records in the audit log,
> some of which (depending on the admin) may be considered cruft

I don't think extra records is a given.  We could implement it so
there wouldn't be duplicate records.

What about filter consistency?  Are we striving to provide path or
inode-based filters for all syscalls that have a pathname argument?
Or just the subset that correlates to Inotify events?

> and,  
> 
> 2) Coherent.  Trying to use getname and path_lookup to catch-all or
> catch-some weakens the hook-set's coherency and makes it harder 
> for someone to infer what the heck is going on by simply looking at
> the code.  I'm of the mind that, in the long run and if possible, its
> better to have a 1-1 hooking stradegy.

Agreed.  What do you think we should do if Inotify isn't willing to
add all the events we need/want?

> > 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.
> 
> Thanks!
> 
> > 
> > The most significant issue is that these syscalls don't generate
> > Inotify events.
> >     sys_access
> 
> So I'm not sure if this is important.  I know it's used right before
> we call unlink in the "rm" command, but the unlink syscall should
> give us the record we want (provided we get it before we drop
> out with -EPERM or whatever)
> 
> >     sys_chdir
> 
> Don't think this is needed.
> 
> >     sys_execve
> 
> I think standalone syscall auditing gets everything we need regarding
> execve.

Maybe for logging, but as I mentioned below, we are currently using
path-based filtering with execve in the sample CAPP config.

> >     sys_swapon
> >     sys_mount
> > 
> 
> Unsure about these two.  Mount might be interesting.
> 
> -tim
> 
> > 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