SELinux preventing sleep. Major risk to setenforce 0 as a temp fix?
by ziphem from LinuxQuestions.org on (#6GW25)
Hi! I've upgraded from F38 to F39, and now my laptop will not sleep; SELinux generates errors, below:
Code:SELinux is preventing systemd-sleep from write access on the directory /sys/firmware/efi/efivars.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that systemd-sleep should be allowed write access on the efivars directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'systemd-sleep' --raw | audit2allow -M my-systemdsleep
# semodule -X 300 -i my-systemdsleep.pp
Additional Information:
Source Context system_u:system_r:systemd_sleep_t:s0
Target Context system_u:object_r:efivarfs_t:s0
Target Objects /sys/firmware/efi/efivars [ dir ]
Source systemd-sleep
Source Path systemd-sleep
Port <Unknown>
Host localhost.localdomain
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-39.2-1.fc39.noarch
Local Policy RPM selinux-policy-targeted-39.2-1.fc39.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name localhost.localdomain
Platform Linux localhost.localdomain 6.6.2-201.fc39.x86_64
#1 SMP PREEMPT_DYNAMIC Wed Nov 22 21:31:42 UTC
2023 x86_64
Alert Count 3
First Seen 2023-12-02 22:29:20 EST
Last Seen 2023-12-03 17:12:23 EST
Local ID b08e6e69-f91c-46b4-b48b-44d8757d7d9b
Raw Audit Messages
type=AVC msg=audit(1701641543.913:54560): avc: denied { write } for pid=102849 comm="systemd-sleep" name="/" dev="efivarfs" ino=1343 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:efivarfs_t:s0 tclass=dir permissive=0
Hash: systemd-sleep,systemd_sleep_t,efivarfs_t,dir,writeI did try the suggested fixes, and this does not work. I have opened a bug report in Bugzilla.
In the meantime, would it be a correct statement that doing temporarily disabling selinux via "sudo setenforce 0" (until an update is made available) is a viable and not horrifically risky action? I know keeping SELinux enabled would be optimal, but having to shut down my laptop several times a day becomes extremely disruptive. I guess I'm looking for a gut check, and in case anyone has alternate solutions they recommend I try or tells me that this is a really bad idea.
As always, thank you!!
Code:SELinux is preventing systemd-sleep from write access on the directory /sys/firmware/efi/efivars.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that systemd-sleep should be allowed write access on the efivars directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'systemd-sleep' --raw | audit2allow -M my-systemdsleep
# semodule -X 300 -i my-systemdsleep.pp
Additional Information:
Source Context system_u:system_r:systemd_sleep_t:s0
Target Context system_u:object_r:efivarfs_t:s0
Target Objects /sys/firmware/efi/efivars [ dir ]
Source systemd-sleep
Source Path systemd-sleep
Port <Unknown>
Host localhost.localdomain
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-39.2-1.fc39.noarch
Local Policy RPM selinux-policy-targeted-39.2-1.fc39.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name localhost.localdomain
Platform Linux localhost.localdomain 6.6.2-201.fc39.x86_64
#1 SMP PREEMPT_DYNAMIC Wed Nov 22 21:31:42 UTC
2023 x86_64
Alert Count 3
First Seen 2023-12-02 22:29:20 EST
Last Seen 2023-12-03 17:12:23 EST
Local ID b08e6e69-f91c-46b4-b48b-44d8757d7d9b
Raw Audit Messages
type=AVC msg=audit(1701641543.913:54560): avc: denied { write } for pid=102849 comm="systemd-sleep" name="/" dev="efivarfs" ino=1343 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:efivarfs_t:s0 tclass=dir permissive=0
Hash: systemd-sleep,systemd_sleep_t,efivarfs_t,dir,writeI did try the suggested fixes, and this does not work. I have opened a bug report in Bugzilla.
In the meantime, would it be a correct statement that doing temporarily disabling selinux via "sudo setenforce 0" (until an update is made available) is a viable and not horrifically risky action? I know keeping SELinux enabled would be optimal, but having to shut down my laptop several times a day becomes extremely disruptive. I guess I'm looking for a gut check, and in case anyone has alternate solutions they recommend I try or tells me that this is a really bad idea.
As always, thank you!!