Re: Is auditing ftruncate useful?

On 2/10/20 3:54 PM, Paul Moore wrote: > 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. > So, this is all reasonable. But why do I get this with fchown which also takes a file descriptor? ... It's this disparity between fchown and ftruncate that caught my attention.