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

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday, July 24, 2018 6:15:54 PM EDT Paul Moore wrote:
> On Tue, Jul 24, 2018 at 10:12 AM Ondrej Mosnacek <omosnace@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.

For any *at function when the dirfd is not AT_FDCWD, it goes badly. If its a 
old style syscall without the dirfd, then if the first character is '/' use 
that. Otherwise concatonate cwd and path and pass it to realpath to sort out.

-Steve

> > 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.