filename not audited for openat() on F28

Discussion:

Jiri Jaburek

2018-04-20 13:20:29 UTC

(Please CC me on replies.)

Hello,
I'm trying to run the audit-test suite on Fedora 28 and am running into
it expecting a name= field in the SYSCALL entry.

augrok --seek=697600 -m1 type==SYSCALL syscall=openat success=no
pid=3951 auid=1000 uid=0 euid=0 suid=0 fsuid=0 gid=0
egid=0 sgid=0 fsgid=0 exit=-13
subj=staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
name=tmp.owfFtgPOjx/new

Fedora 28:

----
time->Fri Apr 20 15:04:59 2018
type=PROCTITLE msg=audit(1524229499.918:366591):
proctitle=2F62696E2F62617368002E2F72756E2E62617368002D647600323734
type=PATH msg=audit(1524229499.918:366591): item=0
name="tmp.J4IQL7Buxe/" inode=1055495 dev=fd:02 mode=040700 ouid=0 ogid=0
rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 nametype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1524229499.918:366591):
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229499.918:366591): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc02f0eaf6 a2=c0 a3=16b6010 items=1
ppid=5275 pid=5276 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=2 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(1524229499.918:366591): avc: denied { create } for
pid=5276 comm="do_openat" name="new"
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
----

RHEL-7.5:

----
time->Fri Apr 20 15:06:59 2018
type=PROCTITLE msg=audit(1524229619.726:56605):
proctitle=72756E636F6E0073746166665F753A6C7370705F746573745F723A6C7370705F746573745F67656E657269635F743A53797374656D4869676800646F5F6F70656E6174002F746D7000746D702E30674C74574A336977622F6E6577006372656174650073746166665F753A6F626A6563745F723A757365725F746D705F743A53
type=PATH msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1524229619.726:56605): item=0 name="tmp.0gLtWJ3iwb/"
inode=1055489 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00
obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 objtype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1524229619.726:56605):
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229619.726:56605): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc1ecd6b57 a2=c0 a3=0 items=2 ppid=20750
pid=20751 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=1595 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
----

The key difference here is probably the absence of

type=PATH msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0

on Fedora 28, which augrok looks for.

Is this expected?

I'm seeing something similar with other syscalls like

creat("/tmp/tmp.9EsMgMuio7/new", 0700)

producing

----
type=PROCTITLE msg=audit(04/20/2018 15:15:35.547:371576) :
proctitle=runcon staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
do_creat /tmp/tmp.9EsMgMuio7/new staff_u:object_r:user_tmp_t:SystemLow
type=PATH msg=audit(04/20/2018 15:15:35.547:371576) : item=0
name=/tmp/tmp.9EsMgMuio7/ inode=1572964 dev=fd:02 mode=dir,700 ouid=root
ogid=root rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023
nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(04/20/2018 15:15:35.547:371576) :
cwd=/usr/local/eal4_testing/audit-test/syscalls
type=SYSCALL msg=audit(04/20/2018 15:15:35.547:371576) : arch=x86_64
syscall=creat success=no exit=EACCES(Permission denied)
a0=0x7ffc41d04af9 a1=0700 a2=0x0 a3=0x0 items=1 ppid=6779 pid=6780
auid=eal uid=root gid=root euid=root suid=root fsuid=root egid=root
sgid=root fsgid=root tty=(none) ses=2 comm=do_creat
exe=/usr/local/eal4_testing/audit-test/utils/bin/do_creat
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(04/20/2018 15:15:35.547:371576) : avc: denied {
create } for pid=6780 comm=do_creat name=new
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
----

but the lack of "/new" in PATH here seems more like a bug.

Thanks,
Jiri

Steve Grubb

2018-04-20 13:37:26 UTC

Permalink

Post by Jiri Jaburek
(Please CC me on replies.)
Hello,
I'm trying to run the audit-test suite on Fedora 28 and am running into
it expecting a name= field in the SYSCALL entry.
augrok --seek=697600 -m1 type==SYSCALL syscall=openat success=no
pid=3951 auid=1000 uid=0 euid=0 suid=0 fsuid=0 gid=0
egid=0 sgid=0 fsgid=0 exit=-13
subj=staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
name=tmp.owfFtgPOjx/new
----
time->Fri Apr 20 15:04:59 2018
proctitle=2F62696E2F62617368002E2F72756E2E62617368002D647600323734
type=PATH msg=audit(1524229499.918:366591): item=0
name="tmp.J4IQL7Buxe/" inode=1055495 dev=fd:02 mode=040700 ouid=0 ogid=0
rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 nametype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229499.918:366591): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc02f0eaf6 a2=c0 a3=16b6010 items=1
ppid=5275 pid=5276 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=2 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(1524229499.918:366591): avc: denied { create } for
pid=5276 comm="do_openat" name="new"
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
----
----
time->Fri Apr 20 15:06:59 2018
proctitle=72756E636F6E0073746166665F753A6C7370705F746573745F723A6C7370705F7
46573745F67656E657269635F743A53797374656D4869676800646F5F6F70656E6174002F74
6D7000746D702E30674C74574A336977622F6E6577006372656174650073746166665F753A6
F626A6563745F723A757365725F746D705F743A53 type=PATH
msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1524229619.726:56605): item=0 name="tmp.0gLtWJ3iwb/"
inode=1055489 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00
obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 objtype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229619.726:56605): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc1ecd6b57 a2=c0 a3=0 items=2 ppid=20750
pid=20751 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=1595 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
----
The key difference here is probably the absence of
type=PATH msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
on Fedora 28, which augrok looks for.
Is this expected?
I'm seeing something similar with other syscalls like
creat("/tmp/tmp.9EsMgMuio7/new", 0700)
producing
----
proctitle=runcon staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
do_creat /tmp/tmp.9EsMgMuio7/new staff_u:object_r:user_tmp_t:SystemLow
type=PATH msg=audit(04/20/2018 15:15:35.547:371576) : item=0
name=/tmp/tmp.9EsMgMuio7/ inode=1572964 dev=fd:02 mode=dir,700 ouid=root
ogid=root rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023
nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
cwd=/usr/local/eal4_testing/audit-test/syscalls
type=SYSCALL msg=audit(04/20/2018 15:15:35.547:371576) : arch=x86_64
syscall=creat success=no exit=EACCES(Permission denied)
a0=0x7ffc41d04af9 a1=0700 a2=0x0 a3=0x0 items=1 ppid=6779 pid=6780
auid=eal uid=root gid=root euid=root suid=root fsuid=root egid=root
sgid=root fsgid=root tty=(none) ses=2 comm=do_creat
exe=/usr/local/eal4_testing/audit-test/utils/bin/do_creat
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(04/20/2018 15:15:35.547:371576) : avc: denied {
create } for pid=6780 comm=do_creat name=new
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0

This record says you were denied create. That means it can report the parent
object and its properties. But it cannot report on the object being created
because it has no properties except an intended name. But it has no device,
inode, owner, label, etc. If the system were in permissive mode, you will
probably get the actual object and its properties.

-Steve

Post by Jiri Jaburek
----
but the lack of "/new" in PATH here seems more like a bug.
Thanks,
Jiri
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit

Jiri Jaburek

2018-04-23 10:24:52 UTC

Permalink

Post by Steve Grubb

Thanks, however I don't know if the reply was to openat() or creat() and
I also don't know if it's an expected change compared to RHEL-7 or if
I should treat it as bug.

Post by Steve Grubb
-Steve

Post by Jiri Jaburek
----
but the lack of "/new" in PATH here seems more like a bug.
Thanks,
Jiri
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit

Steve Grubb

2018-04-23 15:29:31 UTC

Permalink

Post by Jiri Jaburek

Post by Steve Grubb

Post by Jiri Jaburek
(Please CC me on replies.)
Hello,
I'm trying to run the audit-test suite on Fedora 28 and am running into
it expecting a name= field in the SYSCALL entry.
augrok --seek=697600 -m1 type==SYSCALL syscall=openat success=no
pid=3951 auid=1000 uid=0 euid=0 suid=0 fsuid=0 gid=0
egid=0 sgid=0 fsgid=0 exit=-13
subj=staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
name=tmp.owfFtgPOjx/new
----
time->Fri Apr 20 15:04:59 2018
proctitle=2F62696E2F62617368002E2F72756E2E62617368002D647600323734
type=PATH msg=audit(1524229499.918:366591): item=0
name="tmp.J4IQL7Buxe/" inode=1055495 dev=fd:02 mode=040700 ouid=0 ogid=0
rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 nametype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229499.918:366591): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc02f0eaf6 a2=c0 a3=16b6010 items=1
ppid=5275 pid=5276 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=2 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(1524229499.918:366591): avc: denied { create } for
pid=5276 comm="do_openat" name="new"
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
----
----
time->Fri Apr 20 15:06:59 2018
proctitle=72756E636F6E0073746166665F753A6C7370705F746573745F723A6C737070
5F7
46573745F67656E657269635F743A53797374656D4869676800646F5F6F70656E617400
2F74
6D7000746D702E30674C74574A336977622F6E6577006372656174650073746166665F7
53A6 F626A6563745F723A757365725F746D705F743A53 type=PATH
msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1524229619.726:56605): item=0 name="tmp.0gLtWJ3iwb/"
inode=1055489 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00
obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 objtype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229619.726:56605): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc1ecd6b57 a2=c0 a3=0 items=2 ppid=20750
pid=20751 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=1595 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
----
The key difference here is probably the absence of
type=PATH msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
on Fedora 28, which augrok looks for.
Is this expected?
I'm seeing something similar with other syscalls like
creat("/tmp/tmp.9EsMgMuio7/new", 0700)
producing
----
proctitle=runcon staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
do_creat /tmp/tmp.9EsMgMuio7/new staff_u:object_r:user_tmp_t:SystemLow
type=PATH msg=audit(04/20/2018 15:15:35.547:371576) : item=0
name=/tmp/tmp.9EsMgMuio7/ inode=1572964 dev=fd:02 mode=dir,700 ouid=root
ogid=root rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023
nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
cwd=/usr/local/eal4_testing/audit-test/syscalls
type=SYSCALL msg=audit(04/20/2018 15:15:35.547:371576) : arch=x86_64
syscall=creat success=no exit=EACCES(Permission denied)
a0=0x7ffc41d04af9 a1=0700 a2=0x0 a3=0x0 items=1 ppid=6779 pid=6780
auid=eal uid=root gid=root euid=root suid=root fsuid=root egid=root
sgid=root fsgid=root tty=(none) ses=2 comm=do_creat
exe=/usr/local/eal4_testing/audit-test/utils/bin/do_creat
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(04/20/2018 15:15:35.547:371576) : avc: denied {
create } for pid=6780 comm=do_creat name=new
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0

This record says you were denied create. That means it can report the
parent object and its properties. But it cannot report on the object
being created because it has no properties except an intended name. But
it has no device, inode, owner, label, etc. If the system were in
permissive mode, you will probably get the actual object and its
properties.

Thanks, however I don't know if the reply was to openat() or creat()

Both have a denial AVC for the action that the syscall is performing.

Post by Jiri Jaburek
and I also don't know if it's an expected change compared to RHEL-7 or if
I should treat it as bug.

The current behavior is a change. I suspect that because the name is about
all we have at this point, the record was dropped because it cannot be
normalized. IOW, its missing a bunch of fields. The old behavior is nice,
though, because you can see what was denied.

I don't know if this is considered a bug. Paul or Richard might need to say
if this is the new behavior going forward.

-Steve

Post by Jiri Jaburek

Post by Steve Grubb

Post by Jiri Jaburek
----
but the lack of "/new" in PATH here seems more like a bug.
Thanks,
Jiri
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit

Paul Moore

2018-04-23 22:12:45 UTC

Permalink

Post by Steve Grubb

Post by Jiri Jaburek

Post by Steve Grubb

Post by Jiri Jaburek
(Please CC me on replies.)
Hello,
I'm trying to run the audit-test suite on Fedora 28 and am running into
it expecting a name= field in the SYSCALL entry.
augrok --seek=697600 -m1 type==SYSCALL syscall=openat success=no
pid=3951 auid=1000 uid=0 euid=0 suid=0 fsuid=0 gid=0
egid=0 sgid=0 fsgid=0 exit=-13
subj=staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
name=tmp.owfFtgPOjx/new
----
time->Fri Apr 20 15:04:59 2018
proctitle=2F62696E2F62617368002E2F72756E2E62617368002D647600323734
type=PATH msg=audit(1524229499.918:366591): item=0
name="tmp.J4IQL7Buxe/" inode=1055495 dev=fd:02 mode=040700 ouid=0 ogid=0
rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 nametype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229499.918:366591): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc02f0eaf6 a2=c0 a3=16b6010 items=1
ppid=5275 pid=5276 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=2 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(1524229499.918:366591): avc: denied { create } for
pid=5276 comm="do_openat" name="new"
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
----
----
time->Fri Apr 20 15:06:59 2018
proctitle=72756E636F6E0073746166665F753A6C7370705F746573745F723A6C737070
5F7
46573745F67656E657269635F743A53797374656D4869676800646F5F6F70656E617400
2F74
6D7000746D702E30674C74574A336977622F6E6577006372656174650073746166665F7
53A6 F626A6563745F723A757365725F746D705F743A53 type=PATH
msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1524229619.726:56605): item=0 name="tmp.0gLtWJ3iwb/"
inode=1055489 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00
obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 objtype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229619.726:56605): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc1ecd6b57 a2=c0 a3=0 items=2 ppid=20750
pid=20751 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=1595 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
----
The key difference here is probably the absence of
type=PATH msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
on Fedora 28, which augrok looks for.
Is this expected?
I'm seeing something similar with other syscalls like
creat("/tmp/tmp.9EsMgMuio7/new", 0700)
producing
----
proctitle=runcon staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
do_creat /tmp/tmp.9EsMgMuio7/new staff_u:object_r:user_tmp_t:SystemLow
type=PATH msg=audit(04/20/2018 15:15:35.547:371576) : item=0
name=/tmp/tmp.9EsMgMuio7/ inode=1572964 dev=fd:02 mode=dir,700 ouid=root
ogid=root rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023
nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
cwd=/usr/local/eal4_testing/audit-test/syscalls
type=SYSCALL msg=audit(04/20/2018 15:15:35.547:371576) : arch=x86_64
syscall=creat success=no exit=EACCES(Permission denied)
a0=0x7ffc41d04af9 a1=0700 a2=0x0 a3=0x0 items=1 ppid=6779 pid=6780
auid=eal uid=root gid=root euid=root suid=root fsuid=root egid=root
sgid=root fsgid=root tty=(none) ses=2 comm=do_creat
exe=/usr/local/eal4_testing/audit-test/utils/bin/do_creat
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(04/20/2018 15:15:35.547:371576) : avc: denied {
create } for pid=6780 comm=do_creat name=new
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0

This record says you were denied create. That means it can report the
parent object and its properties. But it cannot report on the object
being created because it has no properties except an intended name. But
it has no device, inode, owner, label, etc. If the system were in
permissive mode, you will probably get the actual object and its
properties.

Thanks, however I don't know if the reply was to openat() or creat()

Both have a denial AVC for the action that the syscall is performing.

Post by Jiri Jaburek
and I also don't know if it's an expected change compared to RHEL-7 or if
I should treat it as bug.

The current behavior is a change. I suspect that because the name is about
all we have at this point, the record was dropped because it cannot be
normalized. IOW, its missing a bunch of fields. The old behavior is nice,
though, because you can see what was denied.
I don't know if this is considered a bug. Paul or Richard might need to say
if this is the new behavior going forward.

Richard has been playing with the PATH records most recently so I'll
let him have first crack at answering this ...

--
paul moore
www.paul-moore.com

Richard Guy Briggs

2018-04-24 16:40:50 UTC

Permalink

Can you distill this down to one rule and one action that trigger this
so I can do some testing on other versions? I see no "key=" label on
the rule (explicit or implicit) that triggered it.

This is a bit of a surprise, but I have been doing some work in that
area and I'd like to see if any of it might have caused it. I'm
doubtful, but would like to track it down to see if it was intentional
or not.

Post by Jiri Jaburek
----
time->Fri Apr 20 15:04:59 2018
proctitle=2F62696E2F62617368002E2F72756E2E62617368002D647600323734
type=PATH msg=audit(1524229499.918:366591): item=0
name="tmp.J4IQL7Buxe/" inode=1055495 dev=fd:02 mode=040700 ouid=0 ogid=0
rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 nametype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229499.918:366591): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc02f0eaf6 a2=c0 a3=16b6010 items=1
ppid=5275 pid=5276 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=2 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(1524229499.918:366591): avc: denied { create } for
pid=5276 comm="do_openat" name="new"
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
----
----
time->Fri Apr 20 15:06:59 2018
proctitle=72756E636F6E0073746166665F753A6C7370705F746573745F723A6C7370705F746573745F67656E657269635F743A53797374656D4869676800646F5F6F70656E6174002F746D7000746D702E30674C74574A336977622F6E6577006372656174650073746166665F753A6F626A6563745F723A757365725F746D705F743A53
type=PATH msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1524229619.726:56605): item=0 name="tmp.0gLtWJ3iwb/"
inode=1055489 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00
obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 objtype=PARENT
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
cwd="/usr/local/eal4_testing/audit-test/syscalls"
type=SYSCALL msg=audit(1524229619.726:56605): arch=c000003e syscall=257
success=no exit=-13 a0=3 a1=7ffc1ecd6b57 a2=c0 a3=0 items=2 ppid=20750
pid=20751 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=1595 comm="do_openat"
exe="/usr/local/eal4_testing/audit-test/utils/bin/do_openat"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
----
The key difference here is probably the absence of
type=PATH msg=audit(1524229619.726:56605): item=1
name="tmp.0gLtWJ3iwb/new" objtype=CREATE cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
on Fedora 28, which augrok looks for.
Is this expected?
I'm seeing something similar with other syscalls like
creat("/tmp/tmp.9EsMgMuio7/new", 0700)
producing
----
proctitle=runcon staff_u:lspp_test_r:lspp_test_generic_t:SystemHigh
do_creat /tmp/tmp.9EsMgMuio7/new staff_u:object_r:user_tmp_t:SystemLow
type=PATH msg=audit(04/20/2018 15:15:35.547:371576) : item=0
name=/tmp/tmp.9EsMgMuio7/ inode=1572964 dev=fd:02 mode=dir,700 ouid=root
ogid=root rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023
nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
cwd=/usr/local/eal4_testing/audit-test/syscalls
type=SYSCALL msg=audit(04/20/2018 15:15:35.547:371576) : arch=x86_64
syscall=creat success=no exit=EACCES(Permission denied)
a0=0x7ffc41d04af9 a1=0700 a2=0x0 a3=0x0 items=1 ppid=6779 pid=6780
auid=eal uid=root gid=root euid=root suid=root fsuid=root egid=root
sgid=root fsgid=root tty=(none) ses=2 comm=do_creat
exe=/usr/local/eal4_testing/audit-test/utils/bin/do_creat
subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null)
type=AVC msg=audit(04/20/2018 15:15:35.547:371576) : avc: denied {
create } for pid=6780 comm=do_creat name=new
scontext=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023
tcontext=staff_u:object_r:user_tmp_t:s0 tclass=file permissive=0
----
but the lack of "/new" in PATH here seems more like a bug.
Thanks,
Jiri

- RGB

--
Richard Guy Briggs <***@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Richard Guy Briggs

2018-04-24 20:08:46 UTC

Permalink

Post by Richard Guy Briggs

Can you distill this down to one rule and one action that trigger this
so I can do some testing on other versions? I see no "key=" label on
the rule (explicit or implicit) that triggered it.

I was able to recreate it with:
# auditctl -a always,exit -F arch=b64 -S all -F perm=rwxa -F dir=/tmp/test/ -F key=test_create

and then an unprivileged write to /tmp/test/create with:
$ echo test > /tmp/test/create

Post by Richard Guy Briggs
This is a bit of a surprise, but I have been doing some work in that
area and I'd like to see if any of it might have caused it. I'm
doubtful, but would like to track it down to see if it was intentional
or not.

4.8.15-200.fc24.x86_64 new behaviour
4.7.2-201.fc24.x86_64 new behaviour

4.6.7-300.fc24.x86_64 old behaviour
4.6.7-200.fc23.x86_64 old behaviour

Newer ones were consistent with the two new above and older ones were
consistent with the older two above.

$ git log --oneline stable/linux-4.6.y..stable/linux-4.7.y
stable: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

I see nothing obvious in the 11 patches that metion audit.

Even more narrow, I find:

$ git log --oneline v4.6.7..v4.7.2
on the stable tree tags gives me 7 patches from the audit tree that
don't look obvious (except fc64005 which is some of viro's magic).

I did a quick search for the fedora kernel git tree and didn't find it
except for this:
https://src.fedoraproject.org/cgit/kernel.git
which appears to have vanished. This may be it:
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
but I don't find the tags above.

As Steve mentions, this was reporting a failure to create a file, so it
never existed. The attempted filename is mentioned in the AVC record.
This doesn't help us with rule-generated events.

That same range of kernel versions has 43 changed to fs/namei.c which
will take a little longer to examine...

Post by Richard Guy Briggs

- RGB
--
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

- RGB

--
Richard Guy Briggs <***@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635