Libguestfs - Apr 2023 - [COMMON PATCH 0/1] mlcustomize: skip SELinux relabeling if it's disabled

This patch effectively limits the number of cases when we would want to
do a complete SELinux relabeling on Linux guest conversion.

This was brought to my attention as we've recently had a support case
when the conversion was taking too much time mostly because of
relabeling performed with "setfiles -F".

Although this patch might be worthy of taking as it is, I'd also like to
clarify, do we really need relabeling of the entire file system during
conversion?  What exactly might go wrong here if we don't do that?
Since this process might take hours on VMs big enough, it would be
beneficial to be able to limit number of such cases even further, if
possible. Unfortunately I couldn't find any hints in the libguestfs commit
history as the relabeling code goes back to 0131d6f666 ("New tool:
virt-v2v.").

Roman Kagan (1):
  customize: skip SELinux relabeling if it's disabled

 mlcustomize/SELinux_relabel.ml | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

-- 
2.31.1

From: Roman Kagan <rkagan at virtuozzo.com>

Even if SELinux config file and policy tools are present, SELinux may be
turned off by a setting in that config file, "SELINUX", having a value
of "disabled".

Detect this case and skip relabeling.

Signed-off-by: Roman Kagan <rkagan at virtuozzo.com>
---
 mlcustomize/SELinux_relabel.ml | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/mlcustomize/SELinux_relabel.ml b/mlcustomize/SELinux_relabel.ml
index 5ecf7bd..df1de7b 100644
--- a/mlcustomize/SELinux_relabel.ml
+++ b/mlcustomize/SELinux_relabel.ml
@@ -59,14 +59,24 @@ and use_setfiles g    g#aug_load ();
   debug_augeas_errors g;
 
+  let config_path = "/files/etc/selinux/config" in
+  let config_keys = g#aug_ls config_path in
+  (* SELinux may be disabled via a setting in config file *)
+  let selinux_disabled +    let selinuxmode_path = config_path ^
"/SELINUX" in
+    if array_find selinuxmode_path config_keys then
+      g#aug_get selinuxmode_path = "disabled"
+    else
+      false in
+  if selinux_disabled then
+      failwith "selinux disabled";
+
   (* Get the SELinux policy name, eg. "targeted",
"minimum".
    * Use "targeted" if not specified, just like libselinux does.
    *)
   let policy -    let config_path = "/files/etc/selinux/config" in
     let selinuxtype_path = config_path ^ "/SELINUXTYPE" in
-    let keys = g#aug_ls config_path in
-    if array_find selinuxtype_path keys then
+    if array_find selinuxtype_path config_keys then
       g#aug_get selinuxtype_path
     else
       "targeted" in
-- 
2.31.1

On Fri, Apr 21, 2023 at 09:01:40PM +0300, Andrey Drobyshev
wrote:
> This patch effectively limits the number of cases when we would want to
> do a complete SELinux relabeling on Linux guest conversion.
> 
> This was brought to my attention as we've recently had a support case
> when the conversion was taking too much time mostly because of
> relabeling performed with "setfiles -F".
> 
> Although this patch might be worthy of taking as it is, I'd also like
to
> clarify, do we really need relabeling of the entire file system during
> conversion?  What exactly might go wrong here if we don't do that?
> Since this process might take hours on VMs big enough, it would be
> beneficial to be able to limit number of such cases even further, if
> possible. Unfortunately I couldn't find any hints in the libguestfs
commit
> history as the relabeling code goes back to 0131d6f666 ("New tool:
virt-v2v.").
Relabelling is generally needed because we may have modified or
created files during the conversion.  These will not be labelled
correctly by the libguestfs appliance (as would happen when the guest
runs normally) because whatever SELinux mechanism that does this isn't
running.

If SELinux is enforcing this can and will stop services from starting
up at boot (you will see permission errors), and can even prevent a
guest from booting at all.

Note we don't even have a list of possible files affected because we
run stuff like dracut & rpm.

We should probably only need to relabel over "system directories"
(whatever that means), but we currently relabel over everything
mounted (basically everything mentioned in /etc/fstab) because that's
easier.  The alternate path if setfiles doesn't work touches
/.autorelabel, but that just moves the same work to boot time.

I don't think we've seen a case of labelling taking a long time, but
it could happen.

The patch you posted is fine because if SELinux is disabled then file
labels naturally get out of synch over time, as they won't be set on
newly created files.  This is why setting SELinux to disabled isn't
really a "reversible" operation.  You cannot reenable SELinux
afterwards without first doing a full filesystem relabel and reboot.
(Permissive doesn't have this problem.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v