Hibernation thwarted by SELinux

Ask Fedora
, ,
1

Hi folks!

So I’ve been a happy user of F39 since I got my new laptop and since last week also F40 (upgrade was smooth as butter, thanks for the great work!)

As I’m often on the move with my laptop I’d like to hibernate it when I don’t use it for an extended time. But as I don’t always know upfront how long it’s going to be in my bag I’m using suspend-then-hibernate with a 2hr timer as a ‘best of both worlds’ (without the slow shutdown that hybrid-sleep brings to the table)

First a bit about my laptop’s setup:

  • LUKS encrypted XFS on LVM (no BTRFS for me :slight_smile: )
  • Swap partition in /dev/mapper/main-swap
  • SELinux on

Up until recently (can’t put my finger on it when I started noticing it) the hibernate after being suspended worked perfectly. (I do have other issues with hibernating my laptop, but I’m suspecting my Wi-Fi/BT chip is bad as a colleague does not experience these issues)

So over the weekend I tried digging in a bit more and I found some errors in the journal that pointed to SELinux being the culprit. So one setenforce 0 and hibernation attempt later, it worked again! And afterwards I checked /var/log/audit/audit.log and found the following AVC violations:

type=AVC msg=audit(1714151419.154:21089): avc:  denied  { read } for  pid=101912 comm="systemd-sleep" name="dm-2" dev="devtmpfs" ino=649 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0
type=AVC msg=audit(1714151525.155:21258): avc:  denied  { read } for  pid=102729 comm="systemd-sleep" name="dm-2" dev="devtmpfs" ino=649 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0
type=AVC msg=audit(1714151969.538:21640): avc:  denied  { read } for  pid=105042 comm="systemd-sleep" name="dm-2" dev="devtmpfs" ino=649 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=1
type=AVC msg=audit(1714151969.538:21641): avc:  denied  { open } for  pid=105042 comm="systemd-sleep" path="/dev/dm-2" dev="devtmpfs" ino=649 scontext=system_u:system_r:systemd_sleep_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=1

Seems like a ‘classic’ wrong file label issue, but I can’t find which label it’s supposed to have, as all /dev/dm-* devices have the same labels and it did work before:

brw-rw----.  1 root disk    system_u:object_r:fixed_disk_device_t:s0   253,     0 Apr 26 21:01 dm-0
brw-rw----.  1 root disk    system_u:object_r:fixed_disk_device_t:s0   253,     1 Apr 26 21:01 dm-1
brw-rw----.  1 root disk    system_u:object_r:fixed_disk_device_t:s0   253,     2 Apr 26 21:01 dm-2
brw-rw----.  1 root disk    system_u:object_r:fixed_disk_device_t:s0   253,     3 Apr 26 21:01 dm-3
brw-rw----.  1 root disk    system_u:object_r:fixed_disk_device_t:s0   253,     4 Apr 26 21:01 dm-4
brw-rw----.  1 root disk    system_u:object_r:fixed_disk_device_t:s0   253,     5 Apr 26 21:01 dm-5

So my question is, this changed sometime ago, but before raising it as a bug, I thought I’d check here and see if there’s a solution to this.

Thanks!

Cheers,

Jeff

2

Removed f39

3

The labels look correct, see:

sudo semanage fcontext -l | grep -e /dev/dm

You can create a permissive policy like this:
audit2allow | policycoreutils-python-utils Commands | Man Pages | ManKier

4

Thanks for the reply!

According to the policy it does look correct:

#  semanage fcontext -l | grep -e /dev/dm
/dev/dm-[0-9]+                                     block device       system_u:object_r:fixed_disk_device_t:s0 
/dev/dma_heap/.+                                   character device   system_u:object_r:dma_device_t:s0 
/dev/dmfm.*                                        character device   system_u:object_r:sound_device_t:s0 
/dev/dmmidi.*                                      character device   system_u:object_r:sound_device_t:s0

But for some reason the policy does not (longer?) allow systemd-sleep to touch the disk when trying to hibernate. I tried it again just now to get the journald log entries as well:

Apr 29 15:26:57  systemd-sleep[857121]: Failed to find location to hibernate to: Permission denied
Apr 29 15:26:57  bluetoothd[217024]: Controller resume with wake event 0x0
Apr 29 15:26:57  systemd-sleep[857121]: Couldn't hibernate, will try to suspend again.
5

2273959 – upgrade to F40 beta breaks hibernation: selinux denies access

1 Like
6

The new policy fixes the issue! Thanks for pointing me to it! :slight_smile:

1 Like