Re: Fixing /.autorelabel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux