Re: VFS hooks analysis (pass 1)
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(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit