I’d like to see if I can help (under the limitations of my minimal knowledge of SELinux) with getting you across this last step, but I will need some more precise information. (If I end up at a dead end, I can look into things you might be able to try to reset all your changes)
Can you report exactly what you see as output when you run sudo audit2allow -b after you reboot and then attempt to hibernate? (Or does that command print no text at all?)
Also, can you report exactly what you see as output when you run ls -Z /var/swap/swapfile?
Also, can you report exactly what you see as output when you run sudo rpm-ostree kargs? (for my own personal reference, on my previous Aurora installation where I had set up hibernation and added a few other workarounds, my kernel args were: rhgb quiet root=UUID=a83cfd34-a159-49c0-9a0d-3150ef4b32fd rootflags=subvol=root rw rd.luks.options=discard resume=UUID=a83cfd34-a159-49c0-9a0d-3150ef4b32fd resume_offset=36484195 amdgpu.sg_display=0 acpi_osi='!Windows 2020' rtc_cmos.use_acpi_alarm=1 ostree=/ostree/boot.1/fedora/f76b1f4d1f700d629a89dd479e12134110d1568b79d5c3bc698f468bcd23d2d7/0)
It looks like my SE policies do not survive a reboot!
❯ sudo audit2allow -b
#============= iiosensorproxy_t ==============
#!!!! This avc is allowed in the current policy
allow iiosensorproxy_t sysfs_t:dir add_name;
#============= systemd_logind_t ==============
allow systemd_logind_t swapfile_t:dir search;
I think the issue is that my systemd_hibernate (and my second policy, I used the name systemd_hiber) are missing in my SELinux policies after a reboot. No clue why that happens.
I just tried it again, I can add the systemd_hibernate policy, after which I can execute the systemctl hibernate command, no ‘access denied’ issue but the screen goes black/then to login screen, as expected.
I do a reboot before I add the policy again under a different name systemd_hiber but by that time, as we can now see, my first SE policy is gone!
Great, we’re making progress! Since your sudo audit2allow -b would generate a policy with an extra allowance (for iiosensorproxy_t) which we don’t want to add into the hibernation policy module, it looks like you should probably follow the procedure described at step 13 of the original guide for editing the generated policy. I remember I also had to do a manual policy edit+re-compilation when I had set up hibernation, so step 13’s instructions were part of how I successfully made SELinux allow hibernation.
After you generate the hibernation policy by exactly running the commands listed in step 12 of the original guide, can you report the exact contents of the resulting systemd_hibernate.te file? Also, can you report the exact contents of that file after you’ve edited it to remove the allowance for iiosensorproxy_t? Next, after you exactly run the commands listed in steps 13 and 14 of the original guide (in order to recompile the policy and then add it to the permanent database which is supposed to persist across reboots) and immediately try to hibernate again, what is the output of sudo audit2allow -b? (it’ll probably be the same as before, but I want to double-check) Also, can you upload the output of running sudo semodule -l | grep systemd?
Finally, after you then reboot and try to hibernate again, what is the output of running sudo audit2allow -b again? (based on what you previously reported, I would expect that it might again output allow systemd_logind_t swapfile_t:dir search;, but I want to double-check) And can you again upload the output of running sudo semodule -l | grep systemd?
The args look fine to me, so I think we can stop worrying about Grubby!
/tmp
❯ sudo cat systemd_hibernate.te
module systemd_hibernate 1.0;
require {
type swapfile_t;
type systemd_logind_t;
type iiosensorproxy_t;
type sysfs_t;
type syslogd_var_run_t;
class file write;
class dir { search write };
}
#============= iiosensorproxy_t ==============
allow iiosensorproxy_t sysfs_t:dir write;
allow iiosensorproxy_t sysfs_t:file write;
allow iiosensorproxy_t syslogd_var_run_t:dir search;
#============= systemd_logind_t ==============
allow systemd_logind_t swapfile_t:dir search;
I was not sure if I should remove everything that seemed related to iiosensorproxy_t, I decided to be careful and only remove as little as possible:
/tmp
❯ sudo cat systemd_hibernate.te
module systemd_hibernate 1.0;
require {
type swapfile_t;
type systemd_logind_t;
type sysfs_t;
type syslogd_var_run_t;
class file write;
class dir { search write };
}
#============= systemd_logind_t ==============
allow systemd_logind_t swapfile_t:dir search;
shit, iionsensorproxy_t is still there!!
❯ sudo audit2allow -b
#============= iiosensorproxy_t ==============
allow iiosensorproxy_t sysfs_t:dir write;
allow iiosensorproxy_t sysfs_t:file write;
allow iiosensorproxy_t syslogd_var_run_t:dir search;
#============= systemd_logind_t ==============
#!!!! This avc is allowed in the current policy
allow systemd_logind_t swapfile_t:dir search;
#============= systemd_sleep_t ==============
allow systemd_sleep_t swapfile_t:dir search;
Note that systemd_hiber is my 2nd hibernation policy that I created at my earlier attempts to get this working. But that will most likely also be the “tainted” with iiosensorproxy_t.
I stopped here, did not reboot yet, because I still have iiosensorproxy_t in there even though I removed it!
Maybe I have to remove the systemd_hiber and systemd_hibernate first before trying to create the hibernate policy (and removing the sensoryproxy thing) again?
Ok, the outputs of this command (both before and after your edits) look fine to me!
This should be fine, I believe audit2allow just reports everything which SELinux has blocked since your computer booted up. If that’s true, then I think we should actually expect to see iiosensorproxy_t show up in the output! The thing which is much more interesting to me is that a new entry has showed up for you:
If I remember correctly, the same thing happened to me! I then had to add another SELinux module for this policy change, and afterwards I was able to make hibernation work. To do that, let’s have you try performing the following steps:
Reboot, to clear SELinux’s audit log
Try to hibernate again, to cause SELinux to block hibernation (because it hasn’t yet allowed systemd_sleep_t)
Run sudo audit2allow -b again and post your output (because I’m curious about whether systemd_logind_t will show up again after a reboot)
(corresponds to re-doing step 12 but for systemd_sleep_t) Run cd /tmp and then sudo audit2allow -b -M systemd_sleep (or you can probably choose some other name, as long as you’re consistent in the following steps)
(corresponds to re-doing step 13 but for systemd_sleep_t) Edit the systemd_sleep.te file to remove any references to iiosensorproxy_t. Then run sudo checkmodule -M -m -o systemd_sleep.mod systemd_sleep.te and sudo semodule_package -o systemd_sleep.pp -m systemd_sleep.mod
(corresponds to re-doing step 14 but for systemd_sleep_t) Run sudo semodule -i systemd_sleep.pp. Then try to hibernate again, and see what happens. If it works, reboot and try hibernating again; otherwise, run sudo audit2allow -b again to see if SELinux’s audit log has anything new.
You probably don’t need to remove these earlier modules. But if you want to keep the systemd_hibernate module (which you probably still need) and you want to remove the systemd_hiber module (which you probably don’t need), then you can probably do that by running sudo semodule -r systemd_hiber. I would recommend doing that first and rebooting before trying out my instructions above.
Now I am thinking, can’t we create a script?
The only 3 complex elements:
Calculate swap size. For example, I have 8GB ram on this specific laptop and 8gb zram. I created 20GB swapfile. Maybe it is too big… not sure.
After step 12, the script could simply replace the content to contain only:
module systemd_hibernate 1.0;
require {
type swapfile_t;
type systemd_logind_t;
type sysfs_t;
type syslogd_var_run_t;
class file write;
class dir { search write };
}
#============= systemd_logind_t ==============
allow systemd_logind_t swapfile_t:dir search;
Or maybe even less
3. after reboot the user should run the script again, maybe at first run the script creates a file in /tmp or $HOME/Downloads to recognise this is 2nd run.
4. At second run, creating the second policy, again the script will just use sudo tee -a ... to replace the contents of the file with the above but for systemd_sleep.
Then everyone should be able to apply hibernation to Bluefin OS !
I am considering giving it a try to create the script, but I don’t have another laptop atm to then test it with…
Now that I think about it, it might even be possible to just create a single policy file with both policies right from the start! Then you might only need to go through the SELinux steps once.
This (plus my laziness about trying to think about how to calculate swap file size, glue the resulting UUID and offset into the kernel args, and account for possible edge cases and failure modes for such a script) is why I haven’t tried making a script myself, haha
If you’re really interested in this and you have a spare hard drive or large USB drive, you could probably install bluefin into it and use that for testing whatever you make
