VFS hooks analysis (pass 1)
Amy Griffis
amy.griffis at hp.com
Fri Sep 9 15:21:44 UTC 2005
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
More information about the Linux-audit
mailing list