Hi, MicroOS uses a dracut module to relabel in initrd before jumping into the real system¹. A normal TW on the other hand uses generator to boot into an autorelabel target, relabel and reboot². Any reason why the MicroOS approach couldn't just be used also in the plain old TW case? cu Ludwig [1] https://github.com/kubic-project/microos-tools/blob/master/selinux/98selinux... [2] https://build.opensuse.org/package/show/openSUSE:Factory/selinux-autorelabel -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Mon, May 10, Ludwig Nussel wrote:
Hi,
MicroOS uses a dracut module to relabel in initrd before jumping into the real system¹. A normal TW on the other hand uses generator to boot into an autorelabel target, relabel and reboot². Any reason why the MicroOS approach couldn't just be used also in the plain old TW case?
Fedora/Red Hat switched to the reboot way with the argument, it's the only way to solve all problems. I haven't found any further informations or which problems exactly are not solveable with the initrd approach. Thorsten
cu Ludwig
[1] https://github.com/kubic-project/microos-tools/blob/master/selinux/98selinux... [2] https://build.opensuse.org/package/show/openSUSE:Factory/selinux-autorelabel
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Thorsten Kukuk wrote:
On Mon, May 10, Ludwig Nussel wrote:
MicroOS uses a dracut module to relabel in initrd before jumping into the real system¹. A normal TW on the other hand uses generator to boot into an autorelabel target, relabel and reboot². Any reason why the MicroOS approach couldn't just be used also in the plain old TW case?
Fedora/Red Hat switched to the reboot way with the argument, it's the only way to solve all problems. I haven't found any further informations or which problems exactly are not solveable with the initrd approach.
In that case we could probably unify the code of selinux-autorelabel with the one from microos and always relabel in the initrd. A minor glitch seems to be that systemd tries to always load the policy again¹. The policy does not allow transitioning from system_u:system_r:init_t:s0 to system_u:system_r:init_t:s0. Systemd ignores that, still some annoying warning. Not sure whether a) fixing the policy is the correct thing or b) somehow telling systemd that it should not load the policy again or c) have systemd never load the policy again if there's one loaded already. cu Ludwig [1] https://github.com/systemd/systemd/blob/9578b472f47b733951b9ce107ade36dc33d4... -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Mon, May 17, 2021 at 02:37:00PM +0200, Ludwig Nussel wrote:
A minor glitch seems to be that systemd tries to always load the policy again¹. The policy does not allow transitioning from system_u:system_r:init_t:s0 to system_u:system_r:init_t:s0. Systemd ignores that, still some annoying warning. Not sure whether a) fixing the policy is the correct thing or b) somehow telling systemd that it should not load the policy again or c) have systemd never load the policy again if there's one loaded already.
a and b woule be fine for me. b seems like the better options, but I'm also fine with adding this transition as it doesn't have security implications. I would not go for c as there might be valid use cases for this Johannes -- GPG Key E7C81FA0 EE16 6BCE AD56 E034 BFB3 3ADD 7BF7 29D5 E7C8 1FA0 Subkey fingerprint: 250F 43F5 F7CE 6F1E 9C59 4F95 BC27 DD9D 2CC4 FD66 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg Geschäftsführer: Felix Imendörffer (HRB 36809, AG Nürnberg)
participants (3)
-
Johannes Segitz
-
Ludwig Nussel
-
Thorsten Kukuk