Bug 2021835

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

Hello,

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 !

Benoit

"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.

Hello,

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

Thanks

It looks like we're missing some documentation for enabling SELinux. There's an old article which is still valid:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-working_with_selinux-changing_selinux_modes#sect-Security-Enhanced_Linux-Enabling_and_Disabling_SELinux-Enabling_SELinux

"""
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.

Hello,

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.

Benoit

Switching to selinux-policy for further troubleshooting based on systemd and selinux teams agreement.

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.

I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/968

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

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.

https://access.redhat.com/errata/RHBA-2022:1995