RHEL SELinux Administration and Troubleshooting

Anil Jalela · Published Sep 3, 2026 · 7 min read

SELinux evaluates a mandatory policy decision in addition to ordinary Unix permissions. A denial is evidence that a subject type attempted an operation on an object type that policy did not allow. Disabling enforcement may hide that evidence while exposing the service. The correct response is to confirm the application path, read the AVC, decide whether the behavior is intended and choose a supported boolean, durable label or narrowly reviewed policy change.

Treat SELinux as a separate access-control decision

Discretionary owner/group/mode and ACL checks remain relevant, but passing them does not override SELinux. Labels normally contain user, role, type and level fields; service policy most often depends on types. A temporary chcon change can be lost during relabel. Use semanage fcontext for a durable local mapping and apply it with restorecon.

Booleans expose supported policy choices and can be persistent. Do not toggle a boolean because its name sounds relevant; inspect its description and scope, then test the specific application behavior and unintended access.

Read the complete SELinux decision

Diagnose an AVC without weakening the host

1. Reproduce one authorized request and record UTC time, service and path.
2. Confirm enforcing mode, process context and object context.
3. Query the audit log for the matching AVC and read source type, target type, class and permission.
4. Verify ordinary permissions, resolved paths, mounts and application configuration.
5. Choose the documented standard location/label or supported boolean where it represents intended design.
6. Create a durable local file-context mapping only for the exact custom path, apply and retest.
7. Consider a custom policy module only after review proves the behavior is necessary and narrowly scoped.

Collect SELinux evidence and apply a durable label

getenforce
sestatus
ps -eZ | grep httpd
ls -ldZ /srv/example /srv/example/index.html
ausearch -m AVC,USER_AVC -ts recent
sealert -a /var/log/audit/audit.log 2>/dev/null
getsebool -a | grep httpd
semanage boolean -l | grep httpd
semanage fcontext -a -t httpd_sys_content_t '/srv/example(/.*)?'
restorecon -RFv /srv/example
matchpathcon /srv/example/index.html

• The example label makes content readable to an HTTP service; it does not grant write access. Select the documented type for the real purpose.
• Generated policy suggestions are diagnostic input, not automatically safe policy. Review every allowed class and permission.
• Avoid broad recursive relabeling outside the exact approved path.
• Keep enforcement active during final positive and negative acceptance tests.

Evidence and acceptance criteria

Worked scenario: custom web root works only after disabling SELinux

An Apache virtual host moves content under /srv/customer. Unix permissions permit access, but the files carry a generic type and AVCs show the HTTP process denied read access. Disabling SELinux makes the page load but removes confinement for every service decision.

The administrator confirms the custom path is intended read-only web content, adds a durable httpd_sys_content_t mapping for that exact tree, runs restorecon and retests while enforcing. A separate upload directory receives a purpose-specific writable type only if the application design requires it.

Practical how-to cases

sudo mkdir -p /srv/site
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/site(/.*)?'
sudo restorecon -RFv /srv/site
ls -ldZ /srv/site
matchpathcon /srv/site

sudo semanage port -l | grep http_port_t
sudo semanage port -a -t http_port_t -p tcp 8088
sudo semanage port -l | grep 8088
sudo httpd -t
sudo systemctl restart httpd

getsebool httpd_can_network_connect_db
semanage boolean -l | grep httpd_can_network_connect_db
sudo setsebool -P httpd_can_network_connect_db on
getsebool httpd_can_network_connect_db

sudo ausearch -m AVC,USER_AVC -ts recent -i
sudo sealert -a /var/log/audit/audit.log 2>/dev/null
ps -eZ | grep httpd
ls -lZ /srv/site
namei -om /srv/site/index.html

Independent practice tasks

1. Fix mislabeled web content without disabling SELinux.
2. Configure and remove a custom port type mapping.
3. Compare permissive-domain debugging with global permissive mode.
4. Explain an AVC where Unix permissions, not SELinux, fail first.

For this lesson on RHEL SELinux Troubleshooting, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: setenforce 0 on production removes enforcement as a diagnostic shortcut and can expose unrelated services.
• Unsafe: automatically installing audit2allow output may authorize compromised or misconfigured behavior.
• Unsafe: broad recursive relabeling can break multiple services; define and apply the exact path mapping.

Rewritten knowledge checks

Guided lab and acceptance test

1. Install/start a lab HTTP service and serve its default path.
2. Create a custom read-only web root under /srv with correct Unix permissions.
3. Observe and correlate the SELinux denial without disabling enforcement.
4. Add the exact durable file-context mapping and apply it.
5. Prove the page works and that an unrelated path remains unavailable.
6. Remove the custom mapping/content and restore the original service configuration.

Primary references

• RHEL 10 using SELinux
• RHEL 10 documentation
• RHEL 9 documentation