[systemd-devel] [PATCH] core: let selinux_setup() load policy more than once

[Will Woods]

Hey all,

Currently, systemd refuses to load SELinux policy more than once.

Normal systems don't care, because they either:
a) have initramfs without policy, then load policy after switch-root, or
b) load policy in initramfs, and never switch-root out.

But if you *do* switch-root more than once - which fedup does! - you're
supposed to run selinux_init_load_policy() afterward to ensure that you set up
selinuxfs and load the new SELinux policy correctly.

So: this patchset fixes some weird and subtle upgrade bugs[1] by allowing
systemd to load policy after each switch-root.


The first patch is cosmetic: selinux-setup.c was indented 7 spaces (!?) and it
bothered me too much to leave it alone.

The second patch makes systemd try to load policy regardless of whether or not
SELinux is already initialized.

It also changes the failure behavior slightly: normally if policy load fails
and the user requested enforcing, we freeze the system rather than running
without policy. But if SELinux was already initialized, then we *do* have
policy, so we don't have to freeze.


Diffstat ignoring whitespace:

 src/core/ima-setup.c     |  0
 src/core/selinux-setup.c | 10 ++++------
 2 files changed, 4 insertions(+), 6 deletions(-)


Thanks,

-w


[1] Here's one weird and subtle bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1045864

It turns out there's actually a race between systemd-cryptsetup and
systemd-ask-password-*.path to create /run/systemd/ask-password.

If systemd wins, it labels the directory correctly, but systemd-cryptsetup
doesn't do label_init(), so it doesn't know how to label the directory.

Normally that doesn't matter, because systemd relabels /run after it reloads
policy... but if it doesn't load policy, it doesn't relabel /run, the
directory keeps the wrong label, and then the password agent can't read files
from there, and your boot hangs forever waiting for a password...