How to enable SELinux enforcing on Rocky Linux for stronger security
Edit /etc/selinux/config to set SELINUX=enforcing, run sudo setenforce 1, and verify with sestatus to enable mandatory access control on Rocky Linux.
19 Oct 2025, 08:54 UTC

Useful answer
To enable SELinux enforcing on Rocky Linux, edit /etc/selinux/config and set the line SELINUX=enforcing. Then run sudo setenforce 1 or reboot the system. The change becomes active immediately after the command or on the next boot.
What SELinux enforcing means
SELinux is a kernel module that provides mandatory access control (MAC). Every process and every file is labeled with a security context that includes a type, a level, and optional role information. The kernel consults a policy that is loaded at boot from compiled policy files. In enforcing mode the kernel denies any operation that is not explicitly permitted, which helps stop privilege‑escalation attacks and limits the damage a compromised process can cause.
Each file’s security context is defined by a type such as etc_t for configuration files or httpd_sys_content_t for web content. The type determines which operations are allowed. When a new type is introduced by a policy update, files that already exist keep their old type unless restorecon is run to re‑label them.
Configuration example
# /etc/selinux/config
SELINUX=enforcing
SAVAGE=0
After saving the file, execute the command as root:
sudo setenforce 1
Running setenforce 1 switches the kernel to enforcing mode without a reboot. To temporarily revert, use sudo setenforce 0. The command must be executed with root privileges; ordinary users lack permission to change the mode.
Verification checklist
| Step | Command | Expected result |
|---|---|---|
| Check current mode | sudo sestatus | Current mode: enforcing |
| Attempt restricted access | cat /etc/shadow (as non‑root) | Operation denied; an AVC denial is recorded in /var/log/audit/audit.log |
| Temporarily permissive | sudo setenforce 0 | System runs in permissive mode; the same command succeeds |
| Restore enforcing | sudo setenforce 1 | Mode returns to enforcing; the restricted command fails again |
Limits and common mistakes
Performance impact is modest on modern CPUs; the extra checks add only a small overhead. However, very large or highly dynamic policies can increase CPU usage during enforcement and cause the audit log to grow, potentially exhausting disk space. Monitoring the size of /var/log/audit/audit.log and rotating it regularly helps avoid this issue.
The audit log records every denial as an AVC (Access Vector Cache) entry. Tools like ausearch and audit2why can parse these entries to explain why a denial occurred. Regularly reviewing the log helps identify misconfigurations before they cause service outages.
When a denial is needed for a new service, the audit2allow utility can suggest a custom policy module. However, adding new rules should be done cautiously, as each addition broadens the attack surface.
Misconfiguration is the most frequent source of problems. Leaving SELinux in permissive mode gives a false sense of security because it only logs violations without blocking them. Disabling SELinux to fix a denial removes the protection entirely and may expose the system to exploitation.
Another common mistake is forgetting to run restorecon after a policy update. If file contexts are not refreshed, legitimate services may be denied access, leading to outages. Overly permissive boolean settings can also unintentionally allow actions that were meant to be restricted.
To avoid these issues, always verify the mode with sestatus, test a denial, and keep a record of any restorecon runs. If a service stops working after a policy change, check the audit log for the specific AVC messages and adjust the policy or run restorecon as needed.
If you edit /etc/selinux/config but do not run setenforce 1 or reboot, the system remains in the previous mode, typically permissive. This is a common oversight that leads to the mistaken belief that SELinux is enforcing when it is not.
All commands that modify SELinux state must be run with sudo or as root. Using an unprivileged account will result in a permission error and the change will not take effect.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.