Bug 2019905

Summary:	If selinux labels are not restored, the autorelabel is not enough in RHEL8.4 and recovered system does not boot
Product:	Red Hat Enterprise Linux 8	Reporter:	Welterlen Benoit <bwelterl>
Component:	rear	Assignee:	Pavel Cahyna <pcahyna>
Status:	ASSIGNED ---	QA Contact:	CS System Management SST QE <rhel-cs-system-management-subsystem-qe>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	8.4	CC:	ovasik, pcahyna
Target Milestone:	rc	Flags:	ovasik: needinfo? (pcahyna)
Target Release:	---
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		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:

Description Welterlen Benoit 2021-11-03 15:37:24 UTC

Description of problem:
- When restoring a system with selinux enabled, but where the backup does not restore the label, the system is not bootable because autorelabel will happen to late, systemd already fails with:
---
Failed to create timezone change event source: Permission denied
---

because in RHEL 8.4, systemd is not able to read unlabelled files anymore.

- This case can happen with different backup tools:
- rsync with remote filesystem not able to manage extended attributes
- TSM as customer, because labels for link are no saved, thus /etc/localtime will be unlabelled an systemd will fail.

Version-Release number of selected component (if applicable):
- rear-2.4-18.el8.x86_64
- systemd-239-45.el8_4.1.x86_64
- selinux-policy-targeted-3.14.3-67.el8.noarch
- policycoreutils-2.9-14.el8.x86_64

How reproducible:
- always

Steps to Reproduce:
1. run rear backup on a target that does not support extended attributs
2. recover the system
3. on reboot, the system fails

Actual results:
- recover is complete, but system does not boot and autorelabel can't be applied

Expected results:
- recover completes, and system directly bootable


Additional info:
- I wrote a KCS to workaround the issue with a first boot with enforcing=0 on kernel command line
- I will also open a BZ against selinux because autorelabel is starting to late, systemd failed already.

Comment 1 Pavel Cahyna 2021-11-04 09:08:23 UTC

Hello Benoit, I suppose that the issue does not happen with usual tar (NETFS), because I have not observed this in tests? With BACKUP=RSYNC, the issue does not occur either if the backup destination supports the appropriate extended attributes, or does it?

Comment 2 Welterlen Benoit 2021-11-04 09:34:34 UTC

Hello Pavel,

Thanks for your answer.
Yes, the issue is only seen when labels are not restored correctly (especially /etc/localtime). In this case, the .autorelabel is useless because it can't be applied, systemd is already dead.
 
The solution is to boot with enforcing=0, but this seems complex, because it's a temporary option only for the first boot. I don't know if this is easily feasible (EFI can configure next entry, but legacy ...)

Anyway, the relabel function should be fixed also.

Thank you !

Benoit

Comment 3 Pavel Cahyna 2021-11-04 09:40:17 UTC

Yes, but I am curious if you know under which conditions this does or does not happen, because I thought that ReaR in general relies on relabeling, not restoration of labels - but apparently I was wrong. If you don't know, no problem, I will investigate.

Comment 4 Welterlen Benoit 2021-11-04 09:46:14 UTC

The root cause is that autorelabel can't be reliable anymore in RHEL8.4 because systemd is not able to access unlabelled files any more, and fails before the relabel if /etc/localtime is not labelled for example !

I opened this BZ against rear because I saw the issue with it, and wondering if the workaround can be automatically applied by rear, or at least a warning before the reboot:
if at the end of the process, /etc/localtime is not labelled and selinux in enforcing, WARNING to run the first boot with enforcing=0 to allow the relabel.

But I will also open a BZ against selinux to improve the autorelabel process.

Thank you !

Comment 5 Welterlen Benoit 2021-11-12 08:11:47 UTC

Hello,

I opened a BZ against selinux, and it seems not possible to start autorelabel earlier: https://bugzilla.redhat.com/show_bug.cgi?id=2021835

The specific answer for rear will be to restore the labels before the first reboot:

  # setfiles -c /mnt/local/etc/selinux/target/policy/policy.32 -r /mnt/local/ /mnt/local/etc/selinux/targeted/contexts/files/file_contexts /mnt/local

Thank you !

Benoit