* Is auditing ftruncate useful?
@ 2020-02-05 23:27 Orion Poplawski
2020-02-06 15:37 ` Lenny Bruzenak
0 siblings, 1 reply; 14+ messages in thread
From: Orion Poplawski @ 2020-02-05 23:27 UTC (permalink / raw)
To: linux-audit
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-05 23:27 Is auditing ftruncate useful? Orion Poplawski
@ 2020-02-06 15:37 ` Lenny Bruzenak
2020-02-06 18:12 ` Orion Poplawski
0 siblings, 1 reply; 14+ messages in thread
From: Lenny Bruzenak @ 2020-02-06 15:37 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-06 15:37 ` Lenny Bruzenak
@ 2020-02-06 18:12 ` Orion Poplawski
2020-02-06 18:33 ` Lenny Bruzenak
0 siblings, 1 reply; 14+ messages in thread
From: Orion Poplawski @ 2020-02-06 18:12 UTC (permalink / raw)
To: Lenny Bruzenak, linux-audit
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-06 18:12 ` Orion Poplawski
@ 2020-02-06 18:33 ` Lenny Bruzenak
2020-02-06 19:39 ` Lenny Bruzenak
2020-02-07 19:17 ` Steve Grubb
0 siblings, 2 replies; 14+ messages in thread
From: Lenny Bruzenak @ 2020-02-06 18:33 UTC (permalink / raw)
To: Orion Poplawski, linux-audit
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-06 18:33 ` Lenny Bruzenak
@ 2020-02-06 19:39 ` Lenny Bruzenak
2020-02-07 19:17 ` Steve Grubb
1 sibling, 0 replies; 14+ messages in thread
From: Lenny Bruzenak @ 2020-02-06 19:39 UTC (permalink / raw)
To: Orion Poplawski, linux-audit
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-06 18:33 ` Lenny Bruzenak
2020-02-06 19:39 ` Lenny Bruzenak
@ 2020-02-07 19:17 ` Steve Grubb
2020-02-07 21:56 ` Paul Moore
1 sibling, 1 reply; 14+ messages in thread
From: Steve Grubb @ 2020-02-07 19:17 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-07 19:17 ` Steve Grubb
@ 2020-02-07 21:56 ` Paul Moore
2020-02-07 23:17 ` Orion Poplawski
2020-02-10 22:54 ` Paul Moore
0 siblings, 2 replies; 14+ messages in thread
From: Paul Moore @ 2020-02-07 21:56 UTC (permalink / raw)
To: Steve Grubb, linux-audit
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-07 21:56 ` Paul Moore
@ 2020-02-07 23:17 ` Orion Poplawski
2020-02-10 22:54 ` Paul Moore
1 sibling, 0 replies; 14+ messages in thread
From: Orion Poplawski @ 2020-02-07 23:17 UTC (permalink / raw)
To: Paul Moore, Steve Grubb, linux-audit
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-07 21:56 ` Paul Moore
2020-02-07 23:17 ` Orion Poplawski
@ 2020-02-10 22:54 ` Paul Moore
2020-02-10 23:05 ` Orion Poplawski
1 sibling, 1 reply; 14+ messages in thread
From: Paul Moore @ 2020-02-10 22:54 UTC (permalink / raw)
To: Steve Grubb, linux-audit
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-10 22:54 ` Paul Moore
@ 2020-02-10 23:05 ` Orion Poplawski
2020-02-10 23:29 ` Casey Schaufler
2020-02-11 12:58 ` Paul Moore
0 siblings, 2 replies; 14+ messages in thread
From: Orion Poplawski @ 2020-02-10 23:05 UTC (permalink / raw)
To: Paul Moore, Steve Grubb, linux-audit
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-10 23:05 ` Orion Poplawski
@ 2020-02-10 23:29 ` Casey Schaufler
2020-03-06 16:59 ` Steve Grubb
2020-02-11 12:58 ` Paul Moore
1 sibling, 1 reply; 14+ messages in thread
From: Casey Schaufler @ 2020-02-10 23:29 UTC (permalink / raw)
To: Orion Poplawski, Paul Moore, Steve Grubb, linux-audit
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-10 23:29 ` Casey Schaufler
@ 2020-03-06 16:59 ` Steve Grubb
0 siblings, 0 replies; 14+ messages in thread
From: Steve Grubb @ 2020-03-06 16:59 UTC (permalink / raw)
To: Casey Schaufler; +Cc: linux-audit
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-10 23:05 ` Orion Poplawski
2020-02-10 23:29 ` Casey Schaufler
@ 2020-02-11 12:58 ` Paul Moore
2020-02-12 21:00 ` Orion Poplawski
1 sibling, 1 reply; 14+ messages in thread
From: Paul Moore @ 2020-02-11 12:58 UTC (permalink / raw)
To: Orion Poplawski; +Cc: linux-audit
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is auditing ftruncate useful?
2020-02-11 12:58 ` Paul Moore
@ 2020-02-12 21:00 ` Orion Poplawski
0 siblings, 0 replies; 14+ messages in thread
From: Orion Poplawski @ 2020-02-12 21:00 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-03-06 17:00 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-05 23:27 Is auditing ftruncate useful? Orion Poplawski
2020-02-06 15:37 ` Lenny Bruzenak
2020-02-06 18:12 ` Orion Poplawski
2020-02-06 18:33 ` Lenny Bruzenak
2020-02-06 19:39 ` Lenny Bruzenak
2020-02-07 19:17 ` Steve Grubb
2020-02-07 21:56 ` Paul Moore
2020-02-07 23:17 ` Orion Poplawski
2020-02-10 22:54 ` Paul Moore
2020-02-10 23:05 ` Orion Poplawski
2020-02-10 23:29 ` Casey Schaufler
2020-03-06 16:59 ` Steve Grubb
2020-02-11 12:58 ` Paul Moore
2020-02-12 21:00 ` Orion Poplawski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.