Re: [RFC PATCH ghak9 0/3] audit: Record the path of FDs passed to *at(2) syscalls
On Thu, Jul 26, 2018 at 5:13 AM Ondrej Mosnacek <omosnace(a)redhat.com> wrote:
On Thu, Jul 26, 2018 at 10:12 AM Ondrej Mosnacek
<omosnace(a)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