Diagnosing and Fixing SELinux Context Mismatches in RHEL

The Problem: 'Permission Denied' Despite Correct Ownership

A common failure point in Red Hat Enterprise Linux (RHEL) environments is the application crash or service failure that reports a "Permission denied" error, even when the file system permissions (UID/GID) are correctly configured. When this occurs while SELinux is active, the cause is typically a context mismatch—where the security label assigned to a file or directory does not align with the security policy required by the process attempting to access it.

Diagnostic Quick-Reference

Symptom	Likely Cause	Primary Diagnostic Tool
App logs show 'Permission denied' but ls -l shows 777 or correct owner	Incorrect File Context (Type mismatch)	ls -Z
Service fails to start; systemctl status shows generic failure	AVC Denial (Access Vector Cache)	ausearch
Application can read files but cannot write to a specific directory	Missing SELinux Boolean permission	getsebool

Step-by-Step Verification Process

Follow these checks in order to isolate whether SELinux is the root cause before modifying system policies.

1. Verify SELinux State

   Run the following command as a non-privileged user or root:

   getenforce

   If the output is Disabled, SELinux is not the cause. If Permissive, SELinux is logging errors but not blocking them. If Enforcing, the kernel is actively blocking unauthorized actions based on labels.

2. Search for AVC Denials

   Search the audit logs for Access Vector Cache (AVC) messages. Run this as root or with sudo permissions on the local terminal:

   ausearch -m avc -ts recent

   Look for denied { read write execute } entries. Note the scontext (source context of the process) and the tcontext (target context of the file/port).

3. Inspect File Labels

   Check the security context of the affected path. For example, if an Apache web server cannot access /var/www/html/data:

   ls -Z /var/www/html/data

   The output will show a label like system_u:object_r:default_t:s0. If the type (the second field, e.g., default_t) does not match the expected type for that service (e.g., httpd_sys_content_t), the process will be blocked.

Applying the Fixes

Choose the fix based on the findings from the steps above.

Scenario A: Temporary/Incorrect Labeling

If a file was moved from a home directory to a service directory, it often retains the user_home_t label, which services cannot access. Use restorecon to reset the file to the system default defined in the policy.

# Run as root to restore default contexts recursively
restorecon -Rv /path/to/app

Scenario B: Custom Application Paths

If you are using a non-standard directory (e.g., /opt/myapp/data), the system doesn't know the default label. You must define the context in the SELinux database first, then apply it.

# 1. Define the persistent mapping (requires root)
semanage fcontext -a -t httpd_sys_content_t '/opt/myapp/data(/.*)?'

# 2. Apply the mapping to the filesystem
restorecon -Rv /opt/myapp/data

Risk: Applying an overly permissive label (like unconfined_t) to a public-facing directory creates a security vulnerability.

Scenario C: Missing Boolean Permissions

Some actions are blocked by default regardless of the label (e.g., allowing a web server to connect to a database). Check for relevant booleans:

getsebool -a | grep httpd_can_network_connect

If it is off, enable it persistently:

setsebool -P httpd_can_network_connect on

Verification and Rollback

To verify the fix, restart the affected service and run ausearch -m avc -ts recent again to ensure no new denials are appearing. Use ls -Z to confirm the label matches your semanage command.

Rollback: To remove a custom file context mapping, use:

semanage fcontext -d '/opt/myapp/data(/.*)?'

Follow this with restorecon -Rv /opt/myapp/data to return the files to their previous state.

Escalation Criteria

If the following conditions are met, the issue may require a custom SELinux policy module rather than simple labeling:

• The tcontext is correct, but the scontext is still being denied.
• The application requires a specific system call that is not covered by existing booleans.
• restorecon does not resolve the issue and no relevant booleans exist.