On 2/10/20 3:54 PM, Paul Moore wrote: > On Fri, Feb 7, 2020 at 4:56 PM Paul Moore <[email protected]> wrote: >> On February 7, 2020 2:18:33 PM Steve Grubb <[email protected]> wrote: >>> On Thursday, February 6, 2020 1:33:19 PM EST Lenny Bruzenak wrote: >>>>> Doesn't seem much better: >>>>> >>>>> type=PROCTITLE msg=audit(02/06/2020 10:58:23.626:119631) : >>>>> proctitle=/bin/bash /usr/bin/thunderbird >>>>> type=SYSCALL msg=audit(02/06/2020 10:58:23.626:119631) : arch=x86_64 >>>>> syscall=ftruncate success=yes exit=0 a0=0x4a a1=0x28 a2=0x7f1e41600018 >>>>> a3=0xfffffe00 items=0 ppid=2451 pid=3561 auid=USER uid=USER gid=USER >>>>> euid=USER suid=USER fsuid=USER egid=USER sgid=USER fsgid=USER tty=(none) >>>>> ses=1 comm=thunderbird exe=/usr/lib64/thunderbird/thunderbird >>>>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>>>> key=watched_users >>>>> Why no PATH entry? I have them for things like open: >>>> >>>> The kernel guys can probably answer this accurately. >>> >>> I would have thought that they would have chimed in by now. Since they >>> didn't >>> you might want to file an issue on github. I think you found a problem that >>> someone should look into some day. >> >> One of them (me) is on vacation, and only dealing with emergencies as they >> arise - this isn't one of those. I'm not sure what Richard is doing, but >> you'll get an answer when I'm back in "the office" if Richard doesn't >> comment first. >> >> That said, it's always okay to file a GH issue. > > Generally speaking the only syscalls which generate a PATH record are > those syscalls which take a file pathname as an argument. The reason > why is that pathnames are notoriously transient and are only valid for > the instant they actually resolve to a file; in fact it is possible > that by the time an open(2) syscall returns the fd to the calling > application, the file it opened may no longer be accessible at the > pathname used to open the file. It really is that crazy. > > In the case of ftruncate(2) we see that the syscall doesn't take a > pathname argument, it takes an open file descriptor, this is why you > don't see a PATH record. If we compare it to a syscall which does > take a pathname, e.g. chown(2), we will generate a PATH record. Take > the example below where we use the example program found in the > chown(2) manpage: > > # touch /tmp/test > # auditctl -w /tmp/test -k path_test > # gcc -o chown_test -g chown_test.c > # ./chown_test > ./chown_test <owner> <file> > # ./chown_test nobody /tmp/test > # ausearch -i -k path_test > ---- > type=CONFIG_CHANGE msg=audit(02/10/2020 17:50:45.251:255) : auid=root ses=5 > subj > =unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=add_rule > key=path_test > list=exit res=yes > ---- > type=PROCTITLE msg=audit(02/10/2020 17:51:29.356:258) : > proctitle=./chown_test n > obody /tmp/test > type=PATH msg=audit(02/10/2020 17:51:29.356:258) : item=0 name=/tmp/test > inode=7 > 0660 dev=00:21 mode=file,644 ouid=root ogid=root rdev=00:00 > obj=unconfined_u:obj > ect_r:user_tmp_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 > cap_fver=0 > cap_frootid=0 > type=CWD msg=audit(02/10/2020 17:51:29.356:258) : cwd=/root/tmp > type=SYSCALL msg=audit(02/10/2020 17:51:29.356:258) : arch=x86_64 > syscall=chown > success=yes exit=0 a0=0x7ffc820c0603 a1=nobody a2=unset a3=0x40044e items=1 > ppid > =1678 pid=35451 auid=root uid=root gid=root euid=root suid=root fsuid=root > egid= > root sgid=root fsgid=root tty=pts1 ses=5 comm=chown_test > exe=/root/tmp/chown_tes > t subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=path_test > > ... in the example above we see that we do have a PATH record, as expected. >
So, this is all reasonable. But why do I get this with fchown which also takes a file descriptor? type=PROCTITLE msg=audit(02/06/2020 10:59:30.562:59894) : proctitle=kwin -session 106f726361000123384967700000029380000_1548775895_794186 type=PATH msg=audit(02/06/2020 10:59:30.562:59894) : item=0 name=(null) inode=595335 dev=fd:01 mode=file,600 ouid=USER ogid=USER rdev=00:00 obj=unconfined_u:object_r:config_home_t:s0 objtype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=SYSCALL msg=audit(02/06/2020 10:59:30.562:59894) : arch=x86_64 syscall=fchown success=yes exit=0 a0=0xd a1=0x584b a2=0x584b a3=0xc items=1 ppid=27089 pid=27152 auid=USER uid=USER gid=USER euid=USER suid=USER fsuid=USER egid=USER sgid=USER fsgid=USER tty=(none) ses=16 comm=kwin exe=/usr/bin/kwin subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=perm_mod It's this disparity between fchown and ftruncate that caught my attention. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane [email protected] Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
