Re: Is auditing ftruncate useful?

On Fri, Feb 7, 2020 at 4:56 PM Paul Moore <paul(a)paul-moore.com&gt; wrote: > On February 7, 2020 2:18:33 PM Steve Grubb <sgrubb(a)redhat.com&gt; 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.