On Thu, Jul 26, 2018 at 5:13 AM Ondrej Mosnacek <[email protected]> wrote: > On Thu, Jul 26, 2018 at 10:12 AM Ondrej Mosnacek <[email protected]> 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
