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

[Pino Toscano]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20200624/50e82f40/attachment.sig>