On Sat, 09.07.16 17:52, Richard W.M. Jones (rjo...@redhat.com) wrote: > On Fri, Jul 08, 2016 at 11:50:19AM -0400, Przemek Klosowski 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". > > On the other hand, what is their alternative solution? > > No solution was offered for the general user-initiated /.autorelabel > case. Some specific things were talked about for virt-builder but we > cannot use them for misc other reasons. Here's the upstream thread: > > https://marc.info/?t=146779851900007&r=1&w=2
Maybe an option could be to make libselinux read /run/selinux/config.override instead of /etc/selinux/config, if it exists. In that case some code in the initrd could use that to put selinux into permissive mode if relabelling is requested. (BTW, it's really weird that the flag file is called /.autorelabel... I mean, there's nothing "auto" about it, after all you have to explicitly request it, by creating this file, after all..) Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
