[SOLVED] SELinux preventing sleep. Major risk to setenforce 0 as a temp fix?

ziphem · 12-03-2023, 08:26 PM

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,write

I 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!!

MadeInGermany · 12-04-2023, 09:00 AM

If you disable SELinux you'll fall back to the standard Linux security.
setenforce 0 will still log SELinux violations, but not deny access.
Any time you can return to "enforcing" with setenforce 1.

rclark · 12-04-2023, 11:05 AM

Not risky at all. I always disable SELinux on my systems if OS installed it, as one less thing to deal with. Rely on standard Linux security (which is quite good) and firewalls.

computersavvy · 12-05-2023, 08:18 AM

It may depend upon which version (spin) of fedora you are using.
The immutable versions using ostree are different in management than the standard versions that use dnf.

Additionally, in most spins one could use 'sudo restorecon -R /' to reset the selinux context to what is in the policy and probably eliminate that message.

ziphem · 12-06-2023, 09:29 PM

Got it. This worked, and I'll use it as a quick fix until the bug is resolved. Thanks a ton for the confirmation & information.