On Sat, 09.07.16 21:18, Zbigniew Jędrzejewski-Szmek
(zbyszek(a)in.waw.pl) 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