Is auditing ftruncate useful?

Mon Feb 10 23:05:51 UTC 2020

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?

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                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20200210/f2fbfaf2/attachment.p7s>