From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC PATCH ghak9 0/3] audit: Record the path of FDs passed to *at(2) syscalls Date: Tue, 24 Jul 2018 21:11:32 -0400 Message-ID: <1590186.5EpvlznUaH@x2> References: <20180712113633.10687-1-omosnace@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: rgb@redhat.com, linux-audit@redhat.com List-Id: linux-audit@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 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.