Choosing SELinux Enforcement Mode on Fedora: Enforcing, Permissive, or Disabled

Decision Context

SELinux (Security‑Enhanced Linux) enforces mandatory access controls on Fedora. The three available modes—Enforcing, Permissive, and Disabled—alter how these controls are applied. Choosing the correct mode depends on your security posture, development needs, and operational constraints.

Mode Options Overview

• Enforcing: All policy rules are applied. Unauthorized actions are blocked and logged.
• Permissive: Policy rules are not enforced. Violations are logged only.
• Disabled: SELinux is turned off completely. No policies or audit logs are generated.

Comparison Table

Mode	Security Strength	Audit Visibility	Typical Use Case	Impact on Services
Enforcing	Highest	Full (audit.log)	Production, regulated environments	Services may fail if policies are incomplete
Permissive	Medium (no blocking)	Full (audit.log)	Development, debugging policy issues	Services run; potential hidden problems
Disabled	None	None	Testing, legacy applications	No policy interference; risk of unfiltered access

Trade‑Offs

• Security vs. Flexibility: Enforcing provides the strongest protection but can break services that lack proper policy rules. Disabled offers maximum flexibility but removes all safeguards.
• Debugging vs. Production Readiness: Permissive allows developers to see what would be blocked, but relying on it in production can hide critical violations.
• Operational Overhead: Switching to Enforcing may require updating policies and restarting services, whereas disabling requires no policy maintenance but exposes the system.

Implementation Steps

1. Check Current Mode

   # getenforce
   # sestatus
   

   Both commands must be run as root. getenforce returns "Enforcing", "Permissive", or "Disabled". sestatus shows detailed status including audit settings.

2. Set Desired Mode Temporarily

   # setenforce 0   # 0 = Permissive, 1 = Enforcing
   # setenforce 0   # use 0 to switch to Permissive
   

   Use setenforce for a one‑time change that persists until reboot.

3. Persist Mode Across Reboots

   # sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config
   # sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
   # sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
   

   Replace permissive, enforcing, or disabled accordingly. The file must be edited as root.

4. Restart Services or Reboot

   After changing policies or switching to Enforcing, restart affected services or reboot the system to load new contexts.

Validation Checklist

• Run getenforce again; output must match desired mode.
• Check sestatus for "SELinux status" and audit settings.
• Attempt a controlled violation:

  # su -c 'touch /root/testfile' - user_nonroot
  

  In Enforcing, this should fail with “Permission denied” and a log entry in /var/log/audit/audit.log. In Permissive, the file is created but a denial is logged.

• Review audit log:

  # ausearch -m AVC -ts recent
  

  Ensure entries correspond to the test action.

When to Use Which Mode

• Enforcing: Default for all production Fedora deployments unless a specific application requires a custom policy. Use for servers handling sensitive data or regulated workloads.
• Permissive: Ideal during initial configuration, when integrating new software, or when troubleshooting policy denials. Always review audit logs before promoting to Enforcing.
• Disabled: Reserved for isolated test environments or legacy applications that cannot run with SELinux enabled. Never use on exposed network services.

Practical Example: Switching to Enforcing on a Web Server

Assume a Fedora 38 web server running Apache. The current mode is Permissive.

# getenforce
Permissive

1. Update config:

# sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

2. Apply change immediately:

# setenforce 1

3. Restart Apache:

# systemctl restart httpd

4. Verify:

# getenforce
Enforcing
# sestatus | grep "SELinux status"
SELinux status:                 enabled
SELinux policy name:             targeted
SELinux policy version:         31
SELinux policy booleans:         0

5. Test a denial: as a non‑root user, attempt to write to /var/www/html.

# su -c 'echo test > /var/www/html/testfile' - user_nonroot
bash: /var/www/html/testfile: Permission denied

Check audit log for the AVC denial.

# ausearch -m AVC -ts recent | tail

If the denial appears, the mode is functioning correctly.

Limitations and Mitigations

• Enforcing may break services that lack proper policy rules. Use audit2allow to generate custom modules, but test in Permissive first.
• Permissive hides violations; always review audit logs before moving to Enforcing.
• Disabling removes all SELinux protections; avoid on any system exposed to untrusted networks.

By following this guide, you can confidently select and validate the SELinux mode that aligns with your security objectives and operational needs.