Bug 2075718

Summary:	Having to use "--selinux-relabel" is not intuitive given Red Hat products default to selinux enabled.
Product:	Red Hat Enterprise Linux 9	Reporter:	Germano Veit Michel <gveitmic>
Component:	guestfs-tools	Assignee:	Laszlo Ersek <lersek>
Status:	CLOSED ERRATA	QA Contact:	YongkuiGuo <yoguo>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9.0	CC:	jherrman, kkiwi, lersek, qzhang, rjones, virt-maint, ymao, yoguo
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	guestfs-tools-1.48.2-5.el9	Doc Type:	Bug Fix
Doc Text:	// Relevant for RHEL 9.1 RNs .Using `virt-customize` now works correctly with guests that use SELinux Previously, the `virt-customize` utility did not default to updating SELinux permissions after making modifications to the file system of the virtual machine (VM). As a consequence, if you did not use the `--selinux-relabel` option, the customizations failed to take effect if the VM ran a guest operating system that uses SELinux (such as RHEL). After this update, `--selinux-relabel` is now used by default with `virt-customize`, which prevents the problem from occurring. Note that guests that do not use SELinux are unaffected by this change.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-11-15 09:52:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1554735, 2089748
Bug Blocks:

Description Germano Veit Michel 2022-04-14 23:21:44 UTC

Description of problem:

We default to SELinux enabled everywhere. Having the user to pass "--selinux-relabel" to get correct labels inside the guest when using guestfs tools is counterintuitive, and may impact user experience.

For example, one is more inclined to do this when creating a file inside the Guest:

[Host] touch myfile
[Host] virt-customize -d rhel7.9 --copy-in myfile:/etc/

But the result is an unlabeled file.
[Guest] -rw-r--r--. root root system_u:object_r:unlabeled_t:s0 /etc/myfile

But if one adds "--selinux-relabel", the expected outcome is achieved:

[Host] virt-customize -d rhel7.9 --copy-in myfile:/etc/ --selinux-relabel
[Guest]-rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/myfile

It is a bit unexpected that one needs to explicitly add a toggle to work with selinux. The above is just an example, but there are plenty scenarios where things break if a file inside the Guest is missing a label.

Of course, --selinux-relabel is a much broader option and not every customization/sysprep needs it, so this is debatable from the technical point of view. Still, we want customers to have a good user experience and things to just work.

Some ideas to improve user experience:
a) Check /etc/selinux in the Guest, autodetect and relabel if necessary
b) Check /etc/selinux in the Guest, autodetect and print warning if "--selinux-relabel" not given.

I'd think (b) is good enough, and it would not relabel on cases where its not really needed.

Version-Release number of selected component (if applicable):
libguestfs-1.46.1-3.el9_0.x86_64
guestfs-tools-1.46.1-6.el9.x86_64

Comment 2 YongkuiGuo 2022-04-15 05:00:38 UTC

Hi, Germano

It's a known issue in upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1554735

Comment 3 Germano Veit Michel 2022-04-18 03:01:39 UTC

Thanks YongkuiGuo,

I'll set this one as blocked by the upstream one.

Comment 4 Klaus Heinrich Kiwi 2022-04-20 12:04:29 UTC

I've adjusted the upstream BZ to medium and assigned this to Rich to keep things in sync.

Looks like an easy low-hanging fruit - Rich, you think we could do this to RHEL 9.1?

Comment 5 Laszlo Ersek 2022-05-04 13:49:34 UTC

Let me try to fix this.

Comment 6 Laszlo Ersek 2022-05-10 07:39:13 UTC

Due to how the generator works and how libguestfs-common is consumed, both fixing and testing this BZ is much more complicated than I initially thought.

Comment 7 Laszlo Ersek 2022-05-10 10:53:33 UTC

[libguestfs] SELinux relabeling: do it by default
Message-Id: <d5b51b1e-1489-7e53-124a-a19571518e33>
https://listman.redhat.com/archives/libguestfs/2022-May/028826.html

[libguestfs PATCH 0/2] generator/customize: invert SELinux relabeling default
Message-Id: <20220510102757.14466-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-May/028828.html

[libguestfs-common PATCH 0/2] refresh generated and non-generated files related to "--selinux-relabel"
Message-Id: <20220510104753.14893-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-May/028831.html

[guestfs-tools PATCH] adopt inversion of SELinux relabeling in virt-customize
Message-Id: <20220510105046.15167-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-May/028834.html

[v2v PATCH] adopt inversion of SELinux relabeling in virt-customize
Message-Id: <20220510105307.15402-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-May/028835.html

Comment 8 Laszlo Ersek 2022-05-11 03:46:14 UTC

(In reply to Laszlo Ersek from comment #7)
> [libguestfs] SELinux relabeling: do it by default
> Message-Id: <d5b51b1e-1489-7e53-124a-a19571518e33>
> https://listman.redhat.com/archives/libguestfs/2022-May/028826.html
> 
> [libguestfs PATCH 0/2] generator/customize: invert SELinux relabeling default
> Message-Id: <20220510102757.14466-1-lersek>
> https://listman.redhat.com/archives/libguestfs/2022-May/028828.html

libguestfs commit range 00b9ef239342..08c4ac90f5a3 (including separate commit for common submodule update)

> [libguestfs-common PATCH 0/2] refresh generated and non-generated files
> related to "--selinux-relabel"
> Message-Id: <20220510104753.14893-1-lersek>
> https://listman.redhat.com/archives/libguestfs/2022-May/028831.html

libguestfs-common commit range 81f86a0058a9..48527b8768d7

> [guestfs-tools PATCH] adopt inversion of SELinux relabeling in virt-customize
> Message-Id: <20220510105046.15167-1-lersek>
> https://listman.redhat.com/archives/libguestfs/2022-May/028834.html

guestfs-tools commit 19de3d1c8d4e (with common submodule update squashed)

> [v2v PATCH] adopt inversion of SELinux relabeling in virt-customize
> Message-Id: <20220510105307.15402-1-lersek>
> https://listman.redhat.com/archives/libguestfs/2022-May/028835.html

virt-v2v commit 0c24fc6015ce (with common submodule update squashed)

Comment 10 Richard W.M. Jones 2022-05-15 18:43:21 UTC

A think a better explanation of the bug is something like this:

Previously virt-customize did not default to updating SELinux permissions
after making modifications to the guest filesystem.  This meant that
if you did not use the --selinux-relabel flag explicitly then customizations
made to the guest could fail to work, for guests which use SELinux such
as those running Red Hat Enterprise Linux.

After this update, --selinux-relabel is now the default, so the user
does not need to remember to use this flag.

Guests which do not use SELinux are unaffected by this change.

Comment 11 YongkuiGuo 2022-05-16 04:10:44 UTC

Tested with guestfs-tools-1.48.1-1.el9.x86_64:

Steps:

1. On RHEL9.1 host
# touch testfile

2.
# virt-customize -d rhel9-test --copy-in testfile:/etc
[   0.0] Examining the guest ...
[   5.6] Setting a random seed
[   5.7] Copying: testfile to /etc
[   5.7] SELinux relabelling
[  24.5] Finishing off

3. Inside the guest
# ls -lZ /etc/testfile
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 0 May 16 10:41 /etc/testfile

The --selinux-relabel option has become a default behavior.

Comment 16 YongkuiGuo 2022-07-07 09:56:38 UTC

Verified this bug since the test case for this bug has been automated and passed in the latest nightly compose test.

Comment 18 errata-xmlrpc 2022-11-15 09:52:44 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: guestfs-tools security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:7959