Allow loading compressor modules for zram? (via zram-generator in Fedora 33)

[polarathene]

Recently with Fedora 33 adopting zram by default with the zram-generator systemd project, it's been noticed that attempting to configure the compression algorithm to a compressor not loaded in (zstd, lz4, lz4hc) fails.

Running modprobe zstd would succeed when configuring zram-generator to use zstd. The project is opting to call this command within their code internally to ensure the module is loaded instead like it would on other distros without SELinux. Seems to defeat the purpose of the rule a bit, or is that the preferable solution?

I am not familiar with SELinux, and a quick glance into how allowing the policy to be modified to allow auto loading of compressor modules for zram by zram-generator without it explicitly calling modprobe is unclear. The explicit route is better than setenforce 0 / disabling SELinux completely.

Just raising this issue since the project is related to Fedora 33 release and I've only just realized the behaviour difference against other distros must be due to a SELinux policy somewhere.

[zpytela]

@polarathene can you put here reproducer steps and audited AVC denials?

ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

[polarathene]

Reproduction

Fresh VPS instance of Fedora 33 on Vultr:

Add another zram device with zstd compression (when I tried this on zram0 and rebooted, perhaps due to the failure any systemctl command, the system seemed broken and reported "Connection timed out" errors on failure, SSH also took noticeable longer to suceed):

echo -e "[zram1]\ncompression-algorithm = zstd" >> /usr/lib/systemd/zram-generator.conf
systemctl daemon-reload

dmesg outputs:

zram_generator::generator[1059]: Creating dev-zram0.swap for /dev/zram0 (486MB)
zram_generator::generator[1059]: Creating dev-zram1.swap for /dev/zram1 (486MB)
zram: Added device: zram1

Then running systemctl restart swap.target, dmesg output:

Can't allocate a compression stream
zram: Cannot initialise zstd compressing backend

modprobe zstd, then systemctl restart swap.target and dmesg shows success, which can also be verified with swapon where it is listed:

zram1: detected capacity change from 0 to 509607936
Adding 497660k swap on /dev/zram1.  Priority:100 extents:1 across:497660k SSFS

Restarted with shutdown -r now, journalctl reveals:

Jan 20 21:52:42 vultr.guest systemd-logind[552]: New session 1 of user root.
Jan 20 21:52:42 vultr.guest systemd[1]: Created slice User Slice of UID 0.
Jan 20 21:52:42 vultr.guest systemd[1]: Starting Create swap on /dev/zram1...
Jan 20 21:52:42 vultr.guest systemd[1]: Starting User Runtime Directory /run/user/0...
Jan 20 21:52:42 vultr.guest kernel: Can't allocate a compression stream
Jan 20 21:52:42 vultr.guest kernel: zram: Cannot initialise zstd compressing backend
Jan 20 21:52:42 vultr.guest zram-generator[703]: Error: Failed to configure disk size into /sys/block/zram1/disksize
Jan 20 21:52:42 vultr.guest zram-generator[703]: Caused by:
Jan 20 21:52:42 vultr.guest zram-generator[703]:     Cannot allocate memory (os error 12)
Jan 20 21:52:42 vultr.guest systemd[1]: swap-create@zram1.service: Main process exited, code=exited, status=1/FAILURE
Jan 20 21:52:42 vultr.guest systemd[1]: swap-create@zram1.service: Failed with result 'exit-code'.
Jan 20 21:52:42 vultr.guest systemd[1]: Failed to start Create swap on /dev/zram1.
Jan 20 21:52:42 vultr.guest systemd[1]: Dependency failed for Compressed swap on /dev/zram1.
Jan 20 21:52:42 vultr.guest systemd[1]: dev-zram1.swap: Job dev-zram1.swap/start failed with result 'dependency'.

We can see that this is failing again since we've not loaded the zstd module. This time instead of loading it, setenforce 0 and run systemctl restart swap.target, success again. zstd module has been loaded and zramctl and swapon both show the zram1 device:

Jan 20 21:55:58 vultr.guest dbus-broker-launch[540]: avc:  received setenforce notice (enforcing=0)
Jan 20 21:55:58 vultr.guest systemd[1]: Stopped target Swap.
Jan 20 21:55:58 vultr.guest systemd[1]: Stopping Swap.
Jan 20 21:55:58 vultr.guest systemd[1]: Starting Create swap on /dev/zram1...
Jan 20 21:55:58 vultr.guest kernel: zram1: detected capacity change from 0 to 509607936
Jan 20 21:55:58 vultr.guest zram-generator[777]: Setting up swapspace version 1, size = 486 MiB (509603840 bytes)
Jan 20 21:55:58 vultr.guest zram-generator[777]: no label, UUID=bcbf1885-7a60-4ee9-9901-f0e6a4ea720d
Jan 20 21:55:58 vultr.guest systemd[1]: Finished Create swap on /dev/zram1.
Jan 20 21:55:58 vultr.guest systemd[1]: Activating swap Compressed swap on /dev/zram1...
Jan 20 21:55:58 vultr.guest kernel: Adding 497660k swap on /dev/zram1.  Priority:100 extents:1 across:497660k SSFS
Jan 20 21:55:58 vultr.guest systemd[1]: Activated swap Compressed swap on /dev/zram1.
Jan 20 21:55:58 vultr.guest systemd[1]: Reached target Swap.

Note that with newer versions of zram-generator none of this will occur as it now explicitly calls modprobe zstd when the module isn't loaded. This is just about SELinux blocking implicit loading in general, zram-generator package as reported by dnf info zram-generator is 0.2.0, release 4.fc33, source rust-zram-generator-0.2.0-4.fc33.src.rpm.

---

Audit info

audited AVC denials?

I tried those commands at various stages of the reproduction steps described above and I always received: <no matches>.

I'm pretty certain from the reproduction that SELinux is causing the issue, but unclear how to add an exception.

---

Original PR to resolve the issue on zram-generators side with it's own reproduction steps for testing are available here.