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

OK, so I just wrote a small script to see what PATH records would be generated for a renameat(2) syscall with non-AT_FDCWD fd arguments, and it seems the current implementation is not lacking information, but actually buggy. strace output: openat(AT_FDCWD, "/tmp/tmp.CXtBRafonK/a", O_RDONLY|O_PATH|O_DIRECTORY) = 3 openat(AT_FDCWD, "/tmp/tmp.CXtBRafonK/b", O_RDONLY|O_PATH|O_DIRECTORY) = 4 renameat(3, "f", 4, "g") = 0 close(3) = 0 close(4) = 0 Corresponding audit records for renameat(): type=SYSCALL msg=audit(1532439957.660:5): arch=c000003e syscall=264 success=yes exit=0 a0=3 a1=7ffcc364de2a a2=4 a3=7ffcc364de42 items=4 ppid=594 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="trigger-renamea" exe="/tmp/tmp.GEfuEtn1II/trigger-renameat" subj=system_u:system_r:kernel_t:s0 key=(null) type=CWD msg=audit(1532439957.660:5): cwd="/root/Dokumenty/Kernel"

type=PATH msg=audit(1532439957.660:5): item=0 name="/root/Dokumenty/Kernel" inode=2155 dev=00:1a mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s0 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PATH msg=audit(1532439957.660:5): item=1 name="/root/Dokumenty/Kernel" inode=2156 dev=00:1a mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s0 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PATH msg=audit(1532439957.660:5): item=2 name="f" inode=2157 dev=00:1a mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s0 nametype=DELETE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PATH msg=audit(1532439957.660:5): item=3 name="g" inode=2157 dev=00:1a mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s0 nametype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0

The PARENT paths are incorrectly reporting the CWD path instead of the path of the source/destination directories, even though the inode numbers seem to be correct.

Beyond that, there is really no information in the records that would allow reconstructing which PARENT path belongs to which CREATE/DELETE path... (Intuitively you can guess that src will come before dst, but that is not very reliable.) I think a "parent inode" field in the PATH records could fix this, but maybe there is a better solution...

I'll see if/how I can fix these issues (especially the first one) and then I'll get back to the original issue. renameat() and maybe a few other syscalls should be OK after the fix, but at least openat() will need some further work (right now it only emits just one PATH record with only relative path).