https://bugzilla.suse.com/show_bug.cgi?id=1208071 Bug ID: 1208071 Summary: SELinux: restricting kernel_t causes issues for the way we setup Micro Classification: openSUSE Product: openSUSE Leap Micro Version: 5.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Base Assignee: screening-team-bugs@suse.de Reporter: jsegitz@suse.com QA Contact: qa-bugs@suse.de CC: kukuk@suse.com Found By: --- Blocker: --- 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? -- You are receiving this mail because: You are on the CC list for the bug.