Re: Fixing /.autorelabel

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

 



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




[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