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

[Paul Moore]

On Tue, Jul 24, 2018 at 10:12 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> 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.

-- 
paul moore
www.paul-moore.com