VFS hooks analysis (pass 1)

[Timothy R. Chavez]

On Wednesday 07 September 2005 15:26, Amy Griffis wrote:
> 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.
> 

Just want to say that I personally appreciate all your hard work and analysis
into these matters.

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

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

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.

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

>     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
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
> 
>