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.
Zbyszek