Relabel ephemeral filesystems after initramfs stage if selinux is activated

[davidcassany]

This card is devoted to include the logic provided by packages/cloud-config/oem/10_selinux.yaml as part of the immutable rootfs dracut module.

Why:

• Because the setup of both things is tightly coupled (immutable rootfs is where ephemeral and persistent paths are set)
• Because exposing selinux relabelling setup to users can easily lead to confusion and hard to guess and debug errors
• Because the commonly used /.autorelabel procedure does not work for elemental as it kicks in too late and produces a reboot when done (all changes are lost on reboot), which could lead to an infinite reboot loop.

Despite having already few reasons to code this logic, I believe we should wait a bit and gather further input about the SELinux expectations in elemental scope. Code inside initramfs is tricky and tends to strike back, so I'd be in favor to code it when we have better or more mature picture about what we need regarding SELinux.

[davidcassany]

The card description is still valid and now SELinux has become a priority in Elemental. Just note that that the immutable-rootfs dracut module is no longer valid, as of today the appropriate module is the elemental-rootfs feature.

As stated in the card description it is relevant to note the relabelling should having in initramfs.after or later but before switching root. This way we can be sure changes generated in initramfs are also included.

Alternatively, we could explore if there is some way to configure certain paths to be relabeled right when the policy is loaded. By default SELinux relabels /dev, /dev/shm, /run and /sys/fs/cgroup according to journal logs. I wonder if we could configure it somehow to include extra paths here.

[davidcassany]

Discovered that we can instruct systemd to relabel automatically certain paths after loading a policy, this is exactly what we need in order to relabel ephemeral sensitive paths such as etc.

See comment in https://github.com/systemd/systemd/blob/557c04a382e3ed77d965c79b7b5d74ce78fc1a9c/src/shared/mount-setup.c#L332-L342

Ideally simply adding this relabel file should be enough, but probably we will need force a manual relabel one by one due bsc#1210690 (some extended attributes are lost on copy-up).

Which paths to relabel is the actual question, shall we relabel persistent storage? I'd say yes for now for simplicity, but this could turn to be too much.

[frelon]

Closed in #2074