Re: VFS hooks analysis (pass 1)

> 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