On 2/5/20 4:27 PM, Orion Poplawski wrote: > I would like to track file modifications made by a specific UID.  I have: > > -a exit,never -F dir=/proc/ > -a exit,never -F dir=/var/cache/ > -a exit,never -F path=/etc/passwd -F exe=/usr/bin/kdeinit4 > -a exit,never -F exe=/usr/libexec/gam_server > -a always,exit -F arch=b32 -S > open,truncate,ftruncate,creat,openat,open_by_handle_at -F uid=XXXXX -k > watched_users > -a always,exit -F arch=b64 -S > open,truncate,ftruncate,creat,openat,open_by_handle_at -F uid=XXXXX -k > watched_users > > but as near as I can tell, this is all that gets logged for ftruncate: > > > type=SYSCALL msg=audit(1580944297.114:831002): arch=c000003e syscall=77 > success=yes exit=0 a0=33 a1=28 a2=7f3417100018 a3=1 items=0 ppid=23746 > pid=23816 auid=XXXXX uid=XXXXX gid=XXXXX euid=XXXXX suid=XXXXX fsuid=XXXXX > egid=XXXXX sgid=XXXXX fsgid=XXXXX tty=(none) ses=1 comm=57656220436F6E74656E74 > exe="/usr/lib64/firefox/firefox" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="watched_users" > type=PROCTITLE msg=audit(1580944297.114:831002): > proctitle=2F7573722F6C696236342F66697265666F782F66697265666F78002D636F6E74656E7470726F63002D6368696C6449440031002D6973466F7242726F77736572002D70726566734C656E0031002D707265664D617053697A6500313833303834002D706172656E744275696C644944003230323030313133313131393133002D > > > which does not appear to contain enough information to determine what file was > truncated.  Am I missing something? > > This is on EL7. > For starters, I'd interpret: # ausearch -i -k watched_users LCB

On 2/6/20 11:12 AM, Orion Poplawski 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. My guess is that because with open, the path must be validated, but ftruncate works on a file descriptor; maybe gets no path validation.

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.

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.

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.

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