On Sat, Jul 09, 2016 at 05:31:02AM +0100, Peter Robinson 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 > > How does that work with /run being a tmpfs and losing state between reboots?
The way I understand Lennart's idea, the flag would be used to pass state between the initramfs and the main system. The selinux policy is loaded very early after the transition, but /run is of course shared between the initramfs and host system. So some program could create the flag file at any point in the initramfs, and systemd would "see" the flag file after the transition. > > 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. Yes, that's possible. I'm not a big fan of this approach for the following reason: currently systemd relies on the libselinux code to load the policy, without having to understand the selinux configuration of kernel command-line flags itself. That's a nice separation of concerns. Also, there is no way for systemd to tell the libselinux code to start in permissive mode, so the only option seems to be to not load the policy at all. This seems suboptimal, because of the possible race between the relabelling code, and anything else which creates new files: without the policy loaded they might be created with bad context. Having the policy loaded but permissive should be more robust. > > 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. Yep. It's this round-about-ness that smells wrong to me. Of course if libselinux itself cannot grow the necessary functionality, this would be better then status quo. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
