Runbook: MAC denial - restore service access

This runbook restores service access when MAC (SELinux or AppArmor) is blocking legitimate operations. The procedure differs by cause; the diagnosis step is the same.

When to use this runbook

Use this runbook when:

• A service is failing with permission denied.
• AVC denials appear in the audit log.
• AppArmor denials appear in journalctl -k.
• A recent change (deployment, config, or upgrade) is suspected.

Inputs

Gather before starting:

• The affected service and the error message.
• Recent changes (deploy, config edit, system upgrade).
• The MAC mode (sestatus or aa-status).

Procedure

Step 1: Verify MAC is the cause

# SELinux
sestatus
sudo ausearch -m avc -ts recent

# AppArmor
aa-status
sudo journalctl -k -n 20 | grep apparmor

If there are no recent MAC denials, MAC is not the cause. Investigate other layers.

Step 2: For mislabeled files (SELinux)

ls -lZ <file>
sudo restorecon -v <file>

Verify:

# Re-run the failing operation
sudo systemctl restart <service>
sudo ausearch -m avc -ts recent

Step 3: For missing port types (SELinux)

sudo ausearch -m avc -ts recent | grep tclass=port
sudo semanage port -a -t <type> -p <tcp|udp> <port>

Common types: http_port_t, https_port_t, unreserved_port_t (for high ports).

Step 4: For policy gaps (SELinux)

Generate a policy module:

sudo ausearch -m avc -ts recent | audit2allow -M <name>
cat <name>.te        # REVIEW before installing
sudo semodule -i <name>.pp

Always review the .te file before installing. The policy module allows the specific actions observed; reject anything that grants more access than the application legitimately needs.

Step 5: For AppArmor profile gaps

For a new application:

sudo aa-complain /path/to/binary
# Run the application
sudo aa-logprof

For an existing profile that needs more access:

sudo aa-logprof

Review each suggested change. Edit the profile manually if you need fine control.

Step 6: For debugging (temporary)

# SELinux: make a single domain permissive
sudo semanage permissive -a <domain>

# AppArmor: switch a profile to complain
sudo aa-complain /path/to/binary

These are diagnostic steps. They log denials but allow them. Use to confirm MAC is the cause, then fix properly.

Step 7: Verify

# Re-run the failing operation
sudo systemctl restart <service>
curl ...                 # or whatever was failing

# Verify no new denials
sudo ausearch -m avc -ts recent
sudo journalctl -k -n 20 | grep -E 'apparmor|avc'

Step 8: Document

MAC DENIAL FIX
==============
Service: <service>
Date: 2026-08-09
Symptom: <what was failing>
Diagnosis: <mislabel | port | policy gap | profile gap>
Fix applied: <restorecon | semanage | audit2allow | profile update>
Verification: <curl succeeds, no new denials>
Policy review: <reviewed by, accepted, etc.>

Common patterns

Escalation

Escalate when:

• The fix requires changes to upstream policy (escalate to distribution maintainers).
• A third-party application needs policy changes that affect security (security review).
• The same denial occurs repeatedly (permanent fix).
• MAC was disabled to recover (must be re-enabled).

Bring: affected service, denial log, attempted fix, recommendation.