On Fri, 08.07.16 11:50, Przemek Klosowski (przemek.klosowski@xxxxxxxx) wrote: > On 07/07/2016 04:59 PM, Richard W.M. Jones wrote: > >On Wed, Jul 06, 2016 at 02:52:34PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > >>That patch is the answer to the (repeated) bug reports that relabelling > >>fails if enforcing=1 and the labels are sufficiently messed up. > >>Doing the relabel in permissive mode, without ever going to enforcing > >>mode, seems like the most reliable way out in this case. Starting in > >>enforcing mode first, and then switching back to permissive later > >>is a complication that increased chances of failure. > >Upstream SELinux have comprehensively rejected this approach. They do > >not want to have the presence of /.autorelabel cause SELinux to > >permissive mode. > I kind-of understand why they don't like it: "placing an invisible object in > a special location disables the security system". I must admit, I am not a fan of flag files in the root dir at all either I must say. In particular /forcefsck always has been my favourite bad idea of all... > On the other hand, what is their alternative solution? Well, it's systemd that loads the SELinux policy in the end, at the time we transition from the initrd to the host. We could add a generic flag file for bypassing this to /run. i.e. something like: if /run/systemd/bypass-selinux exists we will not load the selinux policy, and simply proceed without it. (And of course, we could add similar flag files for smack, aa, ima, …). This flags file could then be used by the selinux generator: if the generator runs in the initrd and detects that relabelling is requested it simply creates this flag file. And if the generator runs from the host it instead creates the symlink that replaces default.target to boot into the auto-relabelling mode. The generator would live in some selinux package, but the code for bypassing the selinux policy loading when that flag file exists would be added to systemd. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
