>> >>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? > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
