Diagnosing SELinux AVC Denials on Fedora Workstation and Server

The problem: permission denied with correct file permissions

An application on Fedora starts successfully but cannot read a configuration file, write to its data directory, or bind to a port. The standard ownership and mode look correct, yet the process receives Permission denied. On Fedora Workstation and Server, SELinux runs in enforcing mode by default with the targeted policy. A mandatory access control check can block the operation even when discretionary access control (DAC) permissions allow it.

The useful takeaway: you do not need to disable SELinux. Recent denials are recorded in the audit log as AVC (Access Vector Cache) messages. You can identify the missing rule from those messages and apply a targeted fix such as toggling a boolean, restoring a file context, or installing a local policy module.

Recognizable condition

Look for this combination:

• The application logs Permission denied or fails to start.
• journalctl, dmesg, or /var/log/audit/audit.log contains avc: denied or type=AVC entries.
• The entry shows scontext (source process label) and tcontext (target object label) that do not match an allowed rule.

Cause and diagnostic table

Observed condition	Likely cause	First check
Permission denied despite correct owner and mode; avc: denied in logs	Missing SELinux boolean or incorrect file context	sudo ausearch -m avc -ts recent
ps -eZ shows unconfined_u for the service	Process is not running in a confined SELinux domain	Inspect the systemd unit and service documentation
New application behavior has no matching allow rule	Policy gap for the application's domain	sudo sealert -a /var/log/audit/audit.log
Files copied or restored from another system	File context labeling was lost	matchpathcon -V /path/to/file

Ordered checks

1. Capture recent denials. Run on the Fedora host with sudo or as root. This requires auditd to be running.

   sudo ausearch -m avc -ts recent

   Expected output: one or more type=AVC records with scontext, tcontext, tclass, and op fields. Read-only; no risk.
2. Get a human-readable suggestion.

   sudo sealert -a /var/log/audit/audit.log

   Or for a single alert UUID: sudo sealert -l <alert_uuid>. Review the suggested fix before applying it.
3. Check relevant booleans.

   getsebool -a | grep -i <keyword>

   Replace <keyword> with the service name, such as httpd or named. A boolean is a named SELinux policy switch that permits or denies a class of actions.
4. Verify file contexts.

   matchpathcon -V /path/to/file

   Expected result: verified or a mismatch showing the current context and the expected context. Read-only.
5. Diagnose with a permissive domain only if needed.

   sudo semanage permissive -a <domain_t>

   This logs denials for <domain_t> but does not block them. Use only for diagnosis, not production. Remove it later with sudo semanage permissive -d <domain_t>.
6. Generate a candidate local policy module.

   sudo audit2allow -M localfix < /var/log/audit/audit.log

   Inspect localfix.te before compiling. audit2allow may over-permit by allowing every recorded denial.

Fixes tied to findings

Missing boolean

If getsebool shows the boolean off, enable it persistently:

sudo setsebool -P httpd_can_network_connect on

Replace httpd_can_network_connect with the boolean suggested by sealert. The -P flag writes the setting to disk so it survives reboots. Rollback: sudo setsebool -P httpd_can_network_connect off.

Wrong file context

Restore the default context:

sudo restorecon -Rv /srv/myapp

To make the correct context survive future relabels, add a file context rule first:

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/myapp(/.*)?'
sudo restorecon -Rv /srv/myapp

Replace httpd_sys_content_t and the path with values from matchpathcon or sealert. Rollback: remove the rule with sudo semanage fcontext -d '/srv/myapp(/.*)?' and run restorecon again.

Policy gap for a local application

Compile and install the reviewed module:

sudo semodule -i localfix.pp

Set a higher priority so Fedora policy updates are less likely to shadow it:

sudo semodule -X 400 -i localfix.pp

Rollback: sudo semodule -r localfix.

Lost labeling after restore or copy

Trigger a full relabel on the next boot:

sudo touch /.autorelabel

Then reboot. This can take 10 to 30 minutes on large disks; schedule a maintenance window. Rollback: remove /.autorelabel before rebooting if you need to cancel.

Escalation criteria

• The denial involves a kernel subsystem such as netlink or BPF: file a kernel bug rather than writing a local policy.
• The fix requires an upstream policy change: report to the SELinux policy project with ausearch output and the Fedora version.
• A local module does not stop the denial: ask a maintainer to check whether dontaudit rules are masking secondary denials.
• The problem appeared after a Fedora upgrade: file a Fedora Bugzilla report including dnf history output and the installed selinux-policy version.

Verification

• sestatus should report SELinux status: enabled and Current mode: enforcing.
• Run sudo ausearch -m avc -ts today | wc -l before and after the fix; the count for the target service should drop to zero.
• Restart the workload, for example sudo systemctl restart httpd, and watch sudo journalctl -f -t audit for new AVC messages.
• matchpathcon -V /path/to/file returns verified.
• getsebool <bool_name> shows on.
• semodule -l | grep localfix confirms the custom module is loaded.

Limitations

• Never disable SELinux globally (setenforce 0 or selinux=0) as a permanent fix; it removes mandatory access control for all processes.
• Permissive domains log but do not block; remove them after diagnosis.
• Custom modules from audit2allow can over-permit. Review the .te file before compiling.
• Fedora selinux-policy updates can override local modules; use module priority or re-test after updates.
• Container runtimes such as Podman use separate labels (container_t, container_file_t); host policy changes do not automatically apply inside containers.

These steps cover well-established behavior on Fedora 38 through 41 with the default targeted policy. If a denial persists after the checks above, collect the ausearch output and escalate rather than weakening system policy.