Libguestfs - Jun 2020 - Re: [PATCH libguestfs-common 2/2] mlcustomize: Fall back to autorelabel if specfile does not exist (RHBZ#1828952).

On Tuesday, 5 May 2020 17:44:15 CEST Richard W.M. Jones
wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c2
I think we need to do a different approach than this patch.

The biggest thing is that currently we check only SELINUXTYPE for the
actual policy, however we do not check SELINUX in case SELinux is in
enforcing mode at all.

IMHO we rather need to read /etc/selinux/<SELINUX> first:
- if enforcing, go ahead with the current relabeling: check SELINUXTYPE,
  get the policy path, etc; if set like this, then most probably the
  SELINUXTYPE points to a valid policy, otherwise the guest would not
  even boot
- if permissive or disabled, do not perform any relabeling, including
  touching /.autorelabel; this is because SELinux was disabled, so
  attempting any relabeling might result in failures

-- 
Pino Toscano

On Mon, May 18, 2020 at 11:12:29AM +0200, Pino Toscano
wrote:
> On Tuesday, 5 May 2020 17:44:15 CEST Richard W.M. Jones wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c2
> 
> I think we need to do a different approach than this patch.
> 
> The biggest thing is that currently we check only SELINUXTYPE for the
> actual policy, however we do not check SELINUX in case SELinux is in
> enforcing mode at all.
> 
> IMHO we rather need to read /etc/selinux/<SELINUX> first:
> - if enforcing, go ahead with the current relabeling: check SELINUXTYPE,
>   get the policy path, etc; if set like this, then most probably the
>   SELINUXTYPE points to a valid policy, otherwise the guest would not
>   even boot
> - if permissive or disabled, do not perform any relabeling, including
>   touching /.autorelabel; this is because SELinux was disabled, so
>   attempting any relabeling might result in failures
Permissive and disabled seem to be different cases.  If it's
permissive then SELinux is still "running" (but not enforcing
decisions).

I think the critical thing is actually what SELinux itself does to
update filesystem labels when selinux is set to either permissive or
disabled.  I wasn't able to find any definitive information on this,
but testing by creating a new file in my home directory showed:

SELINUX=enforcing:

$ rm -f test
$ touch test
$ ls -lZ test
-rw-rw-r--. 1 rjones rjones unconfined_u:object_r:user_home_t:s0 0 Jun 24 09:48
test

permissive:
-rw-rw-r--. 1 rjones rjones unconfined_u:object_r:user_home_t:s0 0 Jun 24 09:49
test

disabled:
-rw-rw-r-- 1 rjones rjones ? 0 Jun 24 09:54 test

Anyway I think we at least need to treat enforcing and permissive the
same way.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

On Wednesday, 24 June 2020 10:58:12 CEST Richard W.M. Jones
wrote:
> On Mon, May 18, 2020 at 11:12:29AM +0200, Pino Toscano wrote:
> > On Tuesday, 5 May 2020 17:44:15 CEST Richard W.M. Jones wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c2
> > 
> > I think we need to do a different approach than this patch.
> > 
> > The biggest thing is that currently we check only SELINUXTYPE for the
> > actual policy, however we do not check SELINUX in case SELinux is in
> > enforcing mode at all.
> > 
> > IMHO we rather need to read /etc/selinux/<SELINUX> first:
> > - if enforcing, go ahead with the current relabeling: check
SELINUXTYPE,
> >   get the policy path, etc; if set like this, then most probably the
> >   SELINUXTYPE points to a valid policy, otherwise the guest would not
> >   even boot
> > - if permissive or disabled, do not perform any relabeling, including
> >   touching /.autorelabel; this is because SELinux was disabled, so
> >   attempting any relabeling might result in failures
> 
> Permissive and disabled seem to be different cases.  If it's
> permissive then SELinux is still "running" (but not enforcing
> decisions).
This is true from the POV of the running guest, not so much from the
POV of libguestfs that inspects/manipulate the offline guest.
In this case, both the labels and the policy may be all wrong, and
SELinux will not error out in permissive mode (only "complain").
And at least in case of permissive mode, this is "fine": the
administrator configured the guest that way, as a mild "do not bother
me", so it is expected that labels may be not set/updated. In case they
want to switch SELinux to enforcing, they will need to
a) ensure the policy is correct (including file contexts)
b) relabel all the filesystems
before the actual switch.
> Anyway I think we at least need to treat enforcing and permissive the
> same way.
Because of the above, I think instead that trying to relabel a
permissive guest is not a good idea: we may apply wrong
policies/labels.

-- 
Pino Toscano