On Tue, Jul 12, 2016 at 11:47:56AM +0200, Lennart Poettering wrote: > 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. Right. Or /run/selinux/config.d/whatever.conf, in the systemd drop-in style. This would be very nice for scripts using this functionality, since they could do echo SELINUX=permissive > /run/selinux/config.d/99-autorelabel.conf without worrying about other settings. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
