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

On Tue, Jul 24, 2018 at 10:12 AM Ondrej Mosnacek <omosnace(a)redhat.com&gt;

> 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. Yes, that's odd, and not desirable. > 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 have my suspicions, but I would be curious to hear from Steve how the reconstruction is typically handled.

> 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). Yes, let's fix this first and go from there. Thanks for looking into this.