Bug 2021835

Summary: .autorelabel does not work anymore in RHEL8.4 if a file required by systemd is unlabelled (/etc/localtime)
Product: Red Hat Enterprise Linux 8 Reporter: Welterlen Benoit <bwelterl>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact: Jan Fiala <jafiala>
Priority: medium    
Version: 8.4CC: dwalsh, jafiala, lvrabec, mmalik, msekleta, plautrba, pskhedekar, rmetrich, ssekidde, systemd-maint-list, vmojzis, zpytela
Target Milestone: rcKeywords: Reopened, Triaged
Target Release: 8.6Flags: jafiala: needinfo+
Hardware: All   
OS: Linux   
Fixed In Version: selinux-policy-3.14.3-86.el8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-10 15:15:37 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:

Description Welterlen Benoit 2021-11-10 09:44:24 UTC
Description of problem:
When a file required by systemd is unlabelled, the autorelabel service can't start because system will die earlier because systemd is not able to access unlabelled files anymore

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. boot with selinux=0
2. change the timezone: timedatectl set-timezone Europe/Rome
3. reboot

Actual results:
- The system can't reboot with "failed to create timezone change event source permission denied"
- and .autorelabel does not work ! because systemd can't access /etc/localtime

Expected results:
- autorelabel should fix the issue

Additional info:
- This has been seen with Rear and a rescue system where label of links are not restored: https://bugzilla.redhat.com/show_bug.cgi?id=2019905

Comment 1 Petr Lautrbach 2021-11-11 09:46:47 UTC
I'm afraid it's not possible to "fix" this in policycoreutils. autorelabel is run by systemd quite early but systemd loads selinux policy at very beginning of the boot process and when the policy is loaded, system is enforcing and filesystem is mislabeled, there's no way back. The only fix is to boot in permissive mode.

But if Rear uses the filesystem in disabled mode and knows that it will be used with SELinux enable, it should relabel (changed) files on its own, e.g. using setfiles command:
  # setfiles -c /chroot/etc/selinux/target/policy/policy.32 -r /chroot/ /chroot/etc/selinux/targeted/contexts/files/file_contexts /chroot

Comment 2 Welterlen Benoit 2021-11-16 10:30:56 UTC

The issue is seen with rear because it is one cause of a wrong label, but as said, simply modifying the timezone with selinux disable will make .autorelabel ineffective.
The relabel should happen very early or a transient state should allow systemd/the autorelabel to work in any condition.
autorelabel is expected to work.

Thank you !


Comment 4 Petr Lautrbach 2021-11-16 11:20:26 UTC
"simply modifying the timezone with selinux disabled" means that there's unlabeled file which is important for systemd and apparently systemd can't work without this file. Timezone initialization happens after the policy is loaded and before any service can be run. There's no way for policycoreutils to workaround or fix it unless it's implemented directly in systemd.

Comment 5 Welterlen Benoit 2021-11-16 11:30:16 UTC

If the autorelabel relies on systemd, it must ensure that systemd can effectively execute what is required to relabel the FS.
From RHEL8.4, the policy does not allow systemd to access unlabelled files anymore. It can be /etc/localtime or any other that will make systemd to fail.

=> autorelabel must be executed before any issue might happen
=> if it relies on systemd, a transient 'permissive' state should allow systemd to execute what is needed and selinux should be enabled "for real" once the FS is correctly labelled
=> or autorelabel must rely on something else


Comment 6 Petr Lautrbach 2021-11-16 11:31:38 UTC
It looks like we're missing some documentation for enabling SELinux. There's an old article which is still valid:


Procedure 5.2. Changing to Enforcing Mode

Before SELinux is enabled, each file on the file system must be labeled with an SELinux context. Before this happens, confined domains may be denied access, preventing your system from booting correctly. To prevent this, configure SELINUX=permissive in /etc/selinux/config

So if you need to reliably relabel system and  prevent access denials for systemd on unlabeled files, you need to boot in permissive mode. Or you can relabel the filesystem before reboot using `setfiles` command as described in #c1.

Comment 7 Welterlen Benoit 2021-11-16 11:40:54 UTC

Thanks, will try the setfiles command.

For rear, I think it's far better to have a way inside the process instead of doing an additional reboot.


Comment 11 Zdenek Pytela 2021-12-01 13:34:22 UTC
Switching to selinux-policy for further troubleshooting based on systemd and selinux teams agreement.

Comment 13 Zdenek Pytela 2021-12-01 14:34:10 UTC
Reproduced, the AVC is reported for the lnk_file class, permission read.

We can resolve this particular issue in selinux-policy, but for other cases it is important to follow the two-step procedure to switch from SELinux disabled to permissive. The documentation is expected be updated.

This is probably the first case when it was a symlink which was created in SELinux disabled mode instead of a plain file, and at the same time it was a file which is critical for systemd to continue to reach the selinux-autorelabel.target.

Comment 18 Zdenek Pytela 2021-12-07 16:39:45 UTC
I've submitted a Fedora PR to address the issue:

Comment 19 Zdenek Pytela 2021-12-10 16:11:08 UTC
To backport:
commit 07b06a7f6cb1f41b92de5d29d21ac89c4d362457 (HEAD -> rawhide, upstream/rawhide, origin/rawhide, origin/HEAD)
Author: Zdenek Pytela <zpytela>
Date:   Tue Dec 7 17:15:44 2021 +0100

    Allow systemd read unlabeled symbolic links

Comment 31 errata-xmlrpc 2022-05-10 15:15:37 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 (selinux-policy 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.