F40: selinux-policy-40.22-1 systemd-cryptsetup-generator no longer able to write untis

[Luap99]

My system was no longer able to boot after installing selinux-policy-40.22-1 because systemd couldn't decrypt my extra disks as the systemd-cryptsetup-generator failed to create the units for them.

systemd-cryptsetup-generator[1119]: Failed to generate keydev mount unit: Permission denied
kernel: audit: type=1400 audit(1718826964.334:4): avc:  denied  { write } for  pid=1119 comm="systemd-cryptse" name="systemd" dev="tmpfs" ino=845 scontext=system_u:system_r:systemd_cryptsetup_generator_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=0
(sd-exec-[1112]: /usr/lib/systemd/system-generators/systemd-cryptsetup-generator failed with exit status 1.

Obviously systemd-cryptsetup-generator should be allowed to write where it needs to, I guess /run/systemd/generator/ and /run/systemd/cryptsetup looking at the file paths after a successful boot but I am not sure if there is more.

[zpytela]

@Luap99 There were many related updates since you reported this issue, can you check if it is gone?

[Luap99]

Yes I can check later today

[Luap99]

Same issue with selinux-policy-40.27-1.fc40.noarch

I use the keyfile directive with a different file system label so it must be mounted first. systemd-cryptsetup-generator tries to create directories in /run/systemd/cryptsetup/ as mount point target for the keyfile fs but selinux seems to block blocking access there

I am using chcon system_u:object_r:init_exec_t:s0 /usr/lib/systemd/system-generators/systemd-cryptsetup-generator as work around for now

[lmouelle]

Bumping this @zpytela , I just hit this today on a new Fedora IoT machine

audit: type=1400 audit(1733972150.124:4): avc:  denied  { write } for  pid=658 comm="systemd-cryptse" name="systemd" dev="tmpfs" ino=2 scontext=system_u:system_r:systemd_cryptsetup_generator_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=0

for context, I have multiple LUKS encrypted devices in my /etc/crypttab like so (private data replaced with ...):

device-... UUID=... cryptkey:LABEL=... luks,discard,nofail,keyfile-timout=10s

With a corresponding /etc/fstab like so:

LABEL=... ... auto ro,nofail,x-systemd.device-timeout=10 0 0

My keyfile is attached to a USB drive at this moment with system_u:object_r:dosfs_t labels. I'm able and willing the labels on the USB drive but I'm not sure what is "best" move here

output of rpm -q selinux-policy:
selinux-policy-41.26-1.fc41.noarch

system: Fedora IoT 41

I cannot run the chcon system_u:object_r:init_exec_t:s0 /usr/lib/systemd/system-generators/systemd-cryptsetup-generator workaround since IoT has /usr as a mountpoint on an immutable filesystem by design

[Luap99]

Yes I also have a USB device with my keyfiles on it.

I don't think the issue is the label on the drives, the generator is trying to create mount points in /run/systemd/cryptsetup and that seems to be blocked AFAICT.

[lmouelle]

The best workaround I found for my case (immutable ostree distro) was to place the keyfile on my OS drive under /etc (this is literally the opposite of what I wanted to do). Then it worked. I attempted to create a policy exception with audit2allow but could not get it working

I also fiddled with a yubikey based flow as an alternative but I need unattended boot, and the FIDO2 spec seemingly explicitly forbids that?
Yubico/libfido2#237

Update: Finally got the audit2allow policy working, I'm a noob at this so probably improper but for the benefit of future readers it's this

module hack 1.0;

require {
	type init_var_run_t;
	type systemd_cryptsetup_generator_t;
	class dir write;
	class dir read;
	class dir open;
	class dir create;
	class dir add_name;
	class dir search;
}

#============= systemd_cryptsetup_generator_t ==============
allow systemd_cryptsetup_generator_t init_var_run_t:dir { read write open create add_name search };

Saved this as hack.te

checkmodule -M -m -o hack.mod hack.te
semodule_package -o hack.pp -m hack.mod

[lmouelle]

Created a PR attempting to resolve this: #2488