With 1e8688ea694393c9d918939322b72dfb44a01792 kernel_t isn't an unconfined
domain anymore. This causes issues for us since we load the policy in
selinux-microos-relabel.sh (of microos-tools) before we pivot. Previously that
was okay since kernel_t could do whatever, but with the change kernel_t get
restricted so much that this script doesn't work anymore. 

I tried moving part of the script that do the relabeling into a separate file
and create a module that transitions away from kernel_t into something like
dracut_t (for now unconfined). The problem is that the transition doesn't work
properly in the franken-state of initrd, with half of the system believing not
to be SELinux enabled and the /sysroot part already being aware of SELinux and
the loaded policy.

I smashed my head against this for a while now and want to bring in additional
eyes. I see these options:
- keep kernel_t as unconfined. Don't want to do this, as there's a real benefit
in not having this unconfined. An attacker will be able abuse the kernel_t
permissions, but it significantly raises the bar (try to work a bit with the
current policy loaded in initrd and you'll see how limited you are).
- Ensure a proper transition away from kernel_t for dracut modules. I tried at
this today, but it doesn't work and the test environment is horrible due to the
restriction placed by SELinux. I would prefer that, but I'll have to figure out
why this doesn't work
- Check if systemd's /run/systemd/relabel-extra.d mechanism could be used. I
assume it can't be used directly, but maybe there's a way around this.

Any other ideas on how to approach this?