Is auditing ftruncate useful?

Is auditing ftruncate useful?

[Orion Poplawski]

[-- Attachment #1.1: Type: text/plain, Size: 1696 bytes --]

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.

Thanks!

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion@nwra.com
Boulder, CO 80301                 https://www.nwra.com/


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3799 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Is auditing ftruncate useful?

[Lenny Bruzenak]

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

-- 
LC Bruzenak
MagitekLTD

Re: Is auditing ftruncate useful?

[Orion Poplawski]

[-- Attachment #1.1: Type: text/plain, Size: 4452 bytes --]

On 2/6/20 8:37 AM, Lenny Bruzenak wrote:
> 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
> 

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:

type=PROCTITLE msg=audit(02/06/2020 10:59:05.170:120649) : proctitle=kdeinit4:
konsole [kdeinit] -session 102311da
type=PATH msg=audit(02/06/2020 10:59:05.170:120649) : item=0 name=/etc/passwd
inode=1323462 dev=08:07 mode=file,644 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:passwd_file_t:s0 objtype=NORMAL cap_fp=none cap_fi=none
cap_fe=0 cap_fver=0
type=CWD msg=audit(02/06/2020 10:59:05.170:120649) :  cwd=/home/USER
type=SYSCALL msg=audit(02/06/2020 10:59:05.170:120649) : arch=x86_64
syscall=open success=yes exit=26 a0=0x7fe1b291b552 a1=O_RDONLY|O_CLOEXEC
a2=0x1b6 a3=0x24 items=1 ppid=1 pid=3141 auid=USER uid=USER gid=USER euid=USER
suid=USER fsuid=USER egid=USER sgid=USER fsgid=USER tty=(none) ses=1
comm=konsole exe=/usr/bin/kdeinit4
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watched_users

or even with other rules for fchown:

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

There I only get an inode entry which I'll have to interpret - but that seems
expected for syscalls that operate on file handles.

Thanks.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion@nwra.com
Boulder, CO 80301                 https://www.nwra.com/


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3799 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Is auditing ftruncate useful?

[Lenny Bruzenak]

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.

LCB

-- 
LC Bruzenak
MagitekLTD

Re: Is auditing ftruncate useful?

[Lenny Bruzenak]

On 2/6/20 11:33 AM, Lenny Bruzenak wrote:

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


I agree with you that on the surface at least it seems inconsistent to 
have a PATH record with fchown (having, as you said, the inode number at 
least) but none with ftruncate.

LCB

-- 
LC Bruzenak
MagitekLTD


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Is auditing ftruncate useful?

[Steve Grubb]

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.

https://github.com/linux-audit/audit-kernel/issues

-Steve

Re: Is auditing ftruncate useful?

[Paul Moore]

On February 7, 2020 2:18:33 PM Steve Grubb <sgrubb@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.

--
paul moore
www.paul-moore.com

Re: Is auditing ftruncate useful?

[Orion Poplawski]

[-- Attachment #1.1: Type: text/plain, Size: 1804 bytes --]

On 2/7/20 2:56 PM, Paul Moore wrote:
> 
> On February 7, 2020 2:18:33 PM Steve Grubb <sgrubb@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.
> 
> --
> paul moore
> www.paul-moore.com

Thanks, filed here:

https://github.com/linux-audit/audit-kernel/issues/119

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion@nwra.com
Boulder, CO 80301                 https://www.nwra.com/


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3799 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Is auditing ftruncate useful?

[Paul Moore]

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

-- 
paul moore
www.paul-moore.com

Re: Is auditing ftruncate useful?

[Orion Poplawski]

[-- Attachment #1.1: Type: text/plain, Size: 4951 bytes --]

On 2/10/20 3:54 PM, Paul Moore wrote:
> On Fri, Feb 7, 2020 at 4:56 PM Paul Moore <paul@paul-moore.com> wrote:
>> On February 7, 2020 2:18:33 PM Steve Grubb <sgrubb@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@nwra.com
Boulder, CO 80301                 https://www.nwra.com/


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3799 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 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@paul-moore.com> wrote:
>>> On February 7, 2020 2:18:33 PM Steve Grubb <sgrubb@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.

Re: Is auditing ftruncate useful?

[Paul Moore]

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

First off, it is worth distinguishing between a PATH record with a
valid pathname (the chown(2) case) and a PATH record with an
invalid/NULL pathname (the fchown(2) case).  At this point you
hopefully understand why those PATH records are different, and why
they sometimes have a pathname, and why sometimes they do not.

For syscalls which resolve pathnames the pathname information for the
PATH records are collected as the pathname is resolved (the only time
they are valid).  When the syscall is done, the resolved pathname
information is turned into the PATH records you see.

In the case of fchown(2) there is no pathname resolution, the kernel's
fchown(2) implementation explicitly records the passed file descriptor
for reasons that Casey mentioned: it's security relevant since you are
changing the file's ownership.  The ftruncate(2) syscall isn't
security relevant so there is no explicit attempt to record the file
descriptor information.  This is why fchown(2) generates a pathless
PATH record, and why ftruncate(2) does not.

If you are still curious, I would suggest you take a look at the
kernel code, all the answers are there, and we could always use
another set of hands/eyes ;)

-- 
paul moore
www.paul-moore.com

Re: Is auditing ftruncate useful?

[Orion Poplawski]

[-- Attachment #1.1: Type: text/plain, Size: 5514 bytes --]

On 2/11/20 5:58 AM, Paul Moore wrote:
> On Mon, Feb 10, 2020 at 6:05 PM Orion Poplawski <orion@nwra.com> wrote:
>> On 2/10/20 3:54 PM, Paul Moore wrote:
>>> On Fri, Feb 7, 2020 at 4:56 PM Paul Moore <paul@paul-moore.com> wrote:

>>>
>>> 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.
> 
> First off, it is worth distinguishing between a PATH record with a
> valid pathname (the chown(2) case) and a PATH record with an
> invalid/NULL pathname (the fchown(2) case).  At this point you
> hopefully understand why those PATH records are different, and why
> they sometimes have a pathname, and why sometimes they do not.
> 
> For syscalls which resolve pathnames the pathname information for the
> PATH records are collected as the pathname is resolved (the only time
> they are valid).  When the syscall is done, the resolved pathname
> information is turned into the PATH records you see.
> 
> In the case of fchown(2) there is no pathname resolution, the kernel's
> fchown(2) implementation explicitly records the passed file descriptor
> for reasons that Casey mentioned: it's security relevant since you are
> changing the file's ownership.  The ftruncate(2) syscall isn't
> security relevant so there is no explicit attempt to record the file
> descriptor information.  This is why fchown(2) generates a pathless
> PATH record, and why ftruncate(2) does not.
> 
> If you are still curious, I would suggest you take a look at the
> kernel code, all the answers are there, and we could always use
> another set of hands/eyes ;)

Thank you again for the detailed response.  I was working with RHEL7 stig
rules like:

https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-14/finding/V-72133

which seem to imply some security relevance for ftruncate, and then noticing
that the ftruncate record didn't seem to provide any kind of useful
information at all.  But I can appreciate some cargo-cult like behavior in the
security implementation realm :).


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion@nwra.com
Boulder, CO 80301                 https://www.nwra.com/


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3799 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Is auditing ftruncate useful?

[Steve Grubb]

On Monday, February 10, 2020 6:29:22 PM EST Casey Schaufler wrote:
> On 2/10/2020 3:05 PM, Orion Poplawski wrote:
> > On 2/10/20 3:54 PM, Paul Moore wrote:
> > 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.

Well, security relevant or not, the requirement that the rule meets is 
located here:

https://www.niap-ccevs.org/MMO/PP/-442-/#fau

File and object events (Successful and unsuccessful attempts to create, 
access, delete, modify, modify permissions), 

Since they separate modify and modify permissions, they clearly want changes 
to content. Now, in the real world is that necessary? Maybe only in super 
important scenarios where you have to know any change to anything.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit