To turn SELinux back on after it was disabled, enable it in permissive mode first, reboot, review the denials, force a relabel, and only then move to enforcing. Skipping the permissive stage is how systems end up unable to boot or with services failing on missing labels.
Why the order matters
SELinux relies on correct labels on every file. While it was disabled, nothing created on the system was labeled. Red Hat's RHEL 9 guide says that to avoid boot problems or process failures, you should resolve AVC messages in permissive mode before enforcing.
On the first boot after a change from disabled, SELinux relabels the file systems automatically.
The steps
- Set permissive in the config. In
/etc/selinux/configsetSELINUX=permissiveand keepSELINUXTYPE=targetedunless you have a reason to use another policy. Before this, confirm the kernel parametersselinux=0orenforcing=0are not set. - Reboot. The system starts with SELinux active but only logging.
- Look for denials. As root, run
ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today. If auditd is not running, the guide suggests searchingdmesgfor the SELinux message types instead. - Schedule a relabel. Run
fixfiles -F onboot, which creates/.autorelabelwith the-Foption so files are relabeled at the next boot. The guide says to always be in permissive mode before running it. - Check how the next boot will behave. The guide warns to be sure the system will boot in permissive mode, for example with the
enforcing=0kernel option, because unlabeled files needed by systemd before the relabel service starts can stop a boot. - Reboot and re-check denials. If you see none, change
SELINUX=enforcingand reboot. - Confirm with
getenforce. It should print Enforcing.
If the file system holds a large number of mislabeled objects, the guide notes that starting in permissive mode helps the relabel succeed. By default the relabel uses as many threads as there are cores. fixfiles -T 1 onboot limits it to one.
Custom applications
Software you built or installed outside the package manager may have no policy. The guide gives two routes: run it in the unconfined_service_t domain, or write a policy for it. Treat the first as a stopgap and track it as risk, because that service gets little confinement.
What to record
Write down the date of the change, the denials you fixed, any booleans you set and any custom module you added. Keep the file in the same repo as your host build scripts so the next rebuild gets it right.
Safeguard offers asset discovery and compliance evidence automation if you need to show hosts are tracked and configured to policy, and there is a free scan at gold.safeguard.sh/scan.
Quick check
Can I go straight from disabled to enforcing?
You can, but Red Hat's guide advises against it. Resolve denials in permissive mode first to avoid boot failures and broken services.
What does fixfiles -F onboot do?
It creates /.autorelabel so the file systems are relabeled on the next boot.
Sources
Last reviewed: 19 October 2026.
