SELinux denials: repair the application boundary before generating policy
Labels, supported booleans, and application behavior should be understood before a new allow rule is introduced.
Archive date is an editorial placement, not the original publication date. Published 9 September 2026; documentation reviewed 9 September 2026. Examples describe proposed checks, not customer incidents or measured product results.
An application failing under SELinux enforcement is evidence to investigate, not proof that enforcement must be disabled. The failure may be a mislabeled path, a supported configuration option, or behavior that the service should not be performing.
Capture the actual denial
On a RHEL-family host with SELinux and audit tools installed, begin with read-only inspection:
getenforce
sestatus
sudo ausearch -m AVC,USER_AVC -ts recent
ls -Zd /srv /srv/example-app
The paths are examples. Use the real application path, and preserve timestamps so the denial can be connected to the failed transaction. Absence of an AVC does not prove SELinux is unrelated; inspect the logging state and relevant troubleshooting guidance.
Use the distribution’s supported policy and tools. The SELinux project maintains the userspace tools, while the kernel documentation points to the subsystem and policy resources.
Identify the boundary being crossed
Read the source context, target context, object class, and denied permission. Connect those to the application operation. Is a web process trying to read its content, write an upload directory, contact a database, or access something unrelated?
Check file labeling against the intended path policy. For an approved path, a nonmodifying preview can help:
sudo restorecon -nRv /srv/example-app
The -n preview reports prospective relabeling rather than applying it. A correct custom path may need a persistent file-context definition before any relabel operation; repeatedly applying a temporary label is not a durable deployment method.
Prefer a narrow explanation
If the distribution provides a documented boolean for the intended behavior, review its scope before enabling it. If the service was configured to write into a read-only content path, correcting the application layout may be the better fix.
Do not feed a large collection of historical denials into an automatic policy generator and install the result without review. That can authorize unrelated activity and preserve a misconfiguration as policy.
Validate the change in a pilot
Apply the approved label, configuration, or minimal policy change to a lab or pilot system. Run the previously failing transaction in enforcing mode. Then run an operation that should remain denied. Successful application behavior alone does not prove the boundary stayed narrow.
Reboot or redeploy the pilot where appropriate to confirm the fix survives normal lifecycle operations. A label repair that disappears at the next image rollout is incomplete.
Retain the reason
Keep the denial, diagnosis, exact change, positive test, and negative test. Document any exception with its owner and review date. This turns an operational inconvenience into a repeatable hardening improvement instead of a permanent loss of enforcement.