Is auditing ftruncate useful?

[Casey Schaufler]

On 2/10/2020 3:05 PM, Orion Poplawski wrote:
> On 2/10/20 3:54 PM, Paul Moore wrote:
>> On Fri, Feb 7, 2020 at 4:56 PM Paul Moore <paul at paul-moore.com> wrote:
>>> On February 7, 2020 2:18:33 PM Steve Grubb <sgrubb at redhat.com> 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.

fchown changes the security state (mode bits) of the file,
whereas ftruncate changes the content of the file. The former
is clearly security relevant, the latter is not.