Bug 2256442

Hi Bruno,

This denial does not reproduce out of the box, do you happen to know which changes are needed?

here is the log using full audit:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33
selinux-policy-40.8-1.fc40.noarch
----
time->Tue Jan  2 13:34:25 2024
type=PROCTITLE msg=audit(1704198865.507:253): proctitle=2F7573722F7362696E2F706C796D6F75746864002D2D6D6F64653D7265626F6F74002D2D6174746163682D746F2D73657373696F6E
type=PATH msg=audit(1704198865.507:253): item=0 name="/dev/kmsg" inode=10 dev=00:05 mode=020644 ouid=0 ogid=0 rdev=01:0b obj=system_u:object_r:kmsg_device_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1704198865.507:253): cwd="/"
type=SYSCALL msg=audit(1704198865.507:253): arch=c000003e syscall=257 success=yes exit=9 a0=ffffff9c a1=7fbc53c0350a a2=802 a3=0 items=1 ppid=10111 pid=10112 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="plymouthd" exe="/usr/sbin/plymouthd" subj=system_u:system_r:plymouthd_t:s0 key=(null)
type=AVC msg=audit(1704198865.507:253): avc:  denied  { syslog_read } for  pid=10112 comm="plymouthd" scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=1
type=AVC msg=audit(1704198865.507:253): avc:  denied  { open } for  pid=10112 comm="plymouthd" path="/dev/kmsg" dev="devtmpfs" ino=10 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1704198865.507:253): avc:  denied  { read write } for  pid=10112 comm="plymouthd" name="kmsg" dev="devtmpfs" ino=10 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=1

(In reply to Zdenek Pytela from comment #1)
> Hi Bruno,
> 
> This denial does not reproduce out of the box, do you happen to know which
> changes are needed?

hmm, indeed. The problem seem to happen when we boot the machine after installing a new kernel.

example: https://datawarehouse.cki-project.org/kcidb/tests/10748869

I cannot reproduce it just by installing a kernel and rebooting, so I wonder is the triggering condition.

Happens during shutdown:

type=PROCTITLE msg=audit(01/02/2024 10:27:30.470:537) : proctitle=/usr/sbin/plymouthd --mode=reboot --attach-to-session 
type=PATH msg=audit(01/02/2024 10:27:30.470:537) : item=0 name=/dev/kmsg inode=10 dev=00:05 mode=character,644 ouid=root ogid=root rdev=01:0b obj=system_u:object_r:kmsg_device_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(01/02/2024 10:27:30.470:537) : cwd=/ 
type=SYSCALL msg=audit(01/02/2024 10:27:30.470:537) : arch=x86_64 syscall=openat success=yes exit=9 a0=AT_FDCWD a1=0x7f20c822f50a a2=O_RDWR|O_NONBLOCK a3=0x0 items=1 ppid=22623 pid=22627 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=plymouthd exe=/usr/sbin/plymouthd subj=system_u:system_r:plymouthd_t:s0 key=(null) 
type=AVC msg=audit(01/02/2024 10:27:30.470:537) : avc:  denied  { syslog_read } for  pid=22627 comm=plymouthd scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=1 
type=AVC msg=audit(01/02/2024 10:27:30.470:537) : avc:  denied  { open } for  pid=22627 comm=plymouthd path=/dev/kmsg dev="devtmpfs" ino=10 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=1 
type=AVC msg=audit(01/02/2024 10:27:30.470:537) : avc:  denied  { read write } for  pid=22627 comm=plymouthd name=kmsg dev="devtmpfs" ino=10 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=1 

in enforcing:

type=PROCTITLE msg=audit(01/02/2024 10:31:36.423:223) : proctitle=/usr/sbin/plymouthd --mode=shutdown --attach-to-session 
type=PATH msg=audit(01/02/2024 10:31:36.423:223) : item=0 name=/dev/kmsg inode=10 dev=00:05 mode=character,644 ouid=root ogid=root rdev=01:0b obj=system_u:object_r:kmsg_device_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(01/02/2024 10:31:36.423:223) : cwd=/ 
type=SYSCALL msg=audit(01/02/2024 10:31:36.423:223) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x7f0ce7f9650a a2=O_RDWR|O_NONBLOCK a3=0x0 items=1 ppid=968 pid=974 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=plymouthd exe=/usr/sbin/plymouthd subj=system_u:system_r:plymouthd_t:s0 key=(null) 
type=AVC msg=audit(01/02/2024 10:31:36.423:223) : avc:  denied  { read write } for  pid=974 comm=plymouthd name=kmsg dev="devtmpfs" ino=10 scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=0 

# /usr/lib/systemd/system/plymouth-reboot.service
[Unit]
Description=Show Plymouth Reboot Screen
After=getty display-manager.service plymouth-start.service
Before=systemd-reboot.service
DefaultDependencies=no
ConditionKernelCommandLine=!plymouth.enable=0
ConditionVirtualization=!container

[Service]
ExecStart=/usr/sbin/plymouthd --mode=reboot --attach-to-session
ExecStartPost=-/usr/bin/plymouth show-splash
Type=forking
RemainAfterExit=yes

Test coverage for this bug exists in a form of PR:
 * https://src.fedoraproject.org/tests/selinux/pull-request/461

The PR waits for a review.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle.
Changing version to 40.

FEDORA-2024-883c7e0684 (selinux-policy-40.15-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-883c7e0684

FEDORA-2024-883c7e0684 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-883c7e0684`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-883c7e0684

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-d0565faae7 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-d0565faae7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d0565faae7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-d0565faae7 (selinux-policy-40.16-1.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.