VFS hooks analysis (pass 1)

[Timothy R. Chavez]

On Friday 09 September 2005 10:21, Amy Griffis wrote:
> 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?

Yep.  We only really need one hook to be called, right?  In some cases that'll
look like a post- hook and in some (probably most), that'll look like a pre- hook.
The basic rule of thumb is that we want to call into audit as soon as we have an
inode.  We have the benefit of SYSCALL to piece together the complete picture.

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

Yeah.  I think you're right.

> 
> 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?

I think its safest to just be consistent and do this for all syscalls that
have pathname arguments.

> 
> > 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?

I don't really see why this would be a problem.  

Technically, fsnotify is not a part of Inotify.  It's just that for the time being,
Inotify (and dnotify), are its only users and so fsnotify only implements what
they need.  I don't see why it'd be a problem to introduce more fsnotify
hooks to satisfy another users needs.  Granted, these hooks would make
use of the Inotify "handler" function, but even so, we're not altering Inotify
in any way.  Once we have the hook in, we can wrap our code in #ifdefs,
and delineate it from core Inotify.

Robert?

-tim