[RFC PATCH ghak9 0/3] audit: Record the path of FDs passed to *at(2) syscalls

[Paul Moore]

On Thu, Jul 26, 2018 at 5:13 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> On Thu, Jul 26, 2018 at 10:12 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> > I think it should be possible to collect that information by putting
> > hooks in the right places of the filesystem code (and fixing the
> > current ones).
>
> Hm, after closer look, it seems this won't be doable (at least not
> easily). The PATH record always logs the original path string from
> userspace (and I think we need to preserve this behavior in case
> someone relies on it). In case of PARENT records, it truncates away
> the last component (because it wants to log inode information also for
> the parent directory). If this truncated string ends up empty (i.e.
> the original string had just one component), it just smashes in the
> absolute path of the CWD (which is known), because it pretends no
> *at() syscalls exist and all relative paths are relative to current
> CWD.
>
> So to fix this, we need to do one of the following:
> 1. Add a new field to the PATH records that would specify the path of
> the directory that the value of name=... is relative to. If this is
> CWD, we can just use some special value
> ("(null)"/"(none)"/"(cwd)"/...) or omit the field completely. I prefer
> this approach, because it will best solve the case of renameat(),
> where different PATH records can have different base directories.

It is worth calling extra attention to the fact that we would now be
effectively recording two paths in a single record.  I'm not sure how
much we care about that, but it does increase the chances we blow past
the end of the netlink buffer; although it is worth noting that a
single PATH_MAX entry would do that today.

Also, would this new field remain empty for non-*at syscalls?

> 2. If adding fields is considered A Bad Thing, we could alternatively
> provide this information in separate records (either PATH with special
> nametype or a new record). However in such case we need to somehow
> specify to which PATH records each base directory corresponds. For
> PATH records this could be guessed from their order, but this is a
> fragile thing (changes in filesystem code could change the order).

While this may be a bit more difficult it seems like this is more in
keeping with the current methodology, and would keep the overall audit
logs smaller.  In the case of the *at syscalls I presume you would
create PARENT records for the base directory, omitting it if AT_FDCWD
was used?

I imagine this would also help the traditional rename() syscall?

-- 
paul moore
www.paul-moore.com