On Sat, 09.07.16 21:18, Zbigniew Jędrzejewski-Szmek (zbyszek@xxxxxxxxx) wrote: > On Sat, Jul 09, 2016 at 05:52:52PM +0100, Richard W.M. Jones 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 > > OK, I get why people don't want to enter permissive mode automatically > if /.autorelabel exists. > > Maybe as a compromise, libselinux could be taught to look at a separate > runtime configuration file to check whether permissive mode should be > enabled (e.g. /run/selinux/config)? Then at least it would be possible > to start in permissive mode without having to modify /etc/selinux/config > or muck around with providing a fake /proc/cmdline. Ah, eh, I should have read your mail first, before responding with my other mail... In systemd we pretty commonly support looking for config files in /run and /usr/lib in addition to /etc, in order to support dynamically generated settings and vendor defaults. However, in systemd /etc (as being admin territory) usually overrides both /run and /usr/lib. Hence, in order to follow this scheme I think an selinux config file in /run that overrides one in /etc should probably be called /run/selinux/config.override instead of /run/selinux/config. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
