SELinux denies a service operation · Linux Fix Lab

Symptoms & scope

A confined service fails despite ordinary filesystem permissions.
Audit logs show denied operations with source and target contexts.

Relevant environment

SELinux-enabled Linux with audit utilities; audit-log reading usually requires root. Package names depend on distribution.

Recognizable messages (synthetic examples)

audit: type=1400 avc: denied { read } for pid=410 comm="example" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file permissive=0

The contexts and object class guide diagnosis; the event alone does not justify permitting the action.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

A wrong file label, port label or documented boolean may not match the service configuration.
The application or policy package may contain a regression requiring a supported update.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read-only audit search; run with the privileges needed for audit logs. Recent selects a short window, so use a suitable time range if the failure occurred earlier.

ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent -i

Interpret the result: Compare denied permission, comm, scontext, tcontext and tclass. permissive=1 records a would-be denial that was not enforced.

Check 2

Reads the current SELinux enforcement mode without changing it.

getenforce

Interpret the result: Enforcing supports an active policy restriction; Permissive logs violations without enforcing them, and Disabled needs another explanation for the immediate block.

Evidence-guided next steps

Align service paths, ports or booleans with documented policy

If the denial identifies an intentional nondefault service configuration, inspect the service’s documented SELinux labels and booleans. Correct a wrong label first; otherwise change only the matching port mapping or narrow boolean after recording its previous value.

Precautions: Do not set SELinux permissive globally or generate an audit2allow module as the first response. A denial can be an intended protection.

Recovery / rollback: Restore the previous boolean or port mapping and service setting using the saved values; verify enforcement remains enabled.

Did this solution help you?

Share this solution #

Use a supported policy or application correction

If labels and documented settings are correct, check the distribution’s policy and application updates for the same denied operation. Apply a relevant supported fix with a package/configuration backup, or report a minimal reproducible event with sensitive paths redacted.

Precautions: A broad local allow module can conceal a compromised or misconfigured service. Preserve the original AVC evidence.

Recovery / rollback: Restore the known-good snapshot or supported matching package versions and saved configuration; isolated policy downgrades need distribution guidance.