You restart a service and it fails with Permission denied
You restart a web server after a config change and the service fails immediately. The logs show Permission denied but the file permissions look correct. You suspect SELinux is blocking the request, but you aren't sure if it's actually enforcing rules right now. Or maybe you are setting up a new Fedora box and want to confirm the security posture before deploying it to production. Checking the status is the first step before you start changing policies or hunting down denials.
What's actually happening
SELinux enforces Mandatory Access Control on the kernel level. Unlike standard Linux permissions which are Discretionary Access Control based on user and group, SELinux labels every process and file with a context. The kernel checks the policy before allowing any interaction. The mode determines how the kernel reacts when a check fails.
Enforcing blocks the action and logs a denial. Permissive allows the action but logs what would have been blocked. Disabled turns off the SELinux subsystem entirely. The kernel loads the SELinux module based on the boot parameters and the config file. If the mode is Disabled, the module isn't loaded, so no logging occurs. This makes troubleshooting impossible if you accidentally disable SELinux and then wonder why services break.
Fedora uses the targeted policy type by default. This means only specific daemons are confined by SELinux. Most user processes run unconfined. The sestatus command reports the policy type so you know which rules apply to your workload.
Run sestatus before you guess. The policy version matters more than you think.
How to check the status
Here's how to check the current runtime mode. The getenforce command queries the kernel directly and returns a single word. This is the fastest way to see if SELinux is active.
getenforce
# Returns Enforcing, Permissive, or Disabled immediately.
# This checks the kernel state, not the config file.
# Useful in scripts that need a quick boolean check.
Here's how to get a full report including policy details and persistent configuration. The sestatus command parses the security state and compares the runtime mode against the config file. This output is essential for auditing and verifying that your changes will survive a reboot.
sestatus
# Displays full SELinux status including policy version and mode.
# Shows if the mode is persistent in /etc/selinux/config.
# Useful for auditing and troubleshooting policy mismatches.
# Output includes SELinux mode, policy from config, and current mode.
The output of sestatus contains several lines you should read. The SELinux mode: line shows the runtime state. The Policy from config: line shows what the system will do on the next boot. If these two lines differ, a runtime change is active that will revert when you restart. The Current mode: line confirms the effective state. The Policy MLS/MCS level: line indicates the multilevel security configuration. Fedora Workstation and Server typically use mcs or none depending on the profile.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. The summary often tells you exactly which process was blocked and suggests a fix command.
Verify the configuration
Compare the Current mode line in sestatus output with your requirements. If you see Enforcing, the system is blocking violations. If you see Permissive, violations are logged but allowed. If the Mode from config line differs from Current mode, a runtime change is active that will revert on reboot.
Here's how to inspect the persistent configuration file. The file /etc/selinux/config controls the mode after reboot. Always check this file to ensure your intended mode is saved.
# /etc/selinux/config
# This file controls the persistent SELinux mode.
# Changes here require a reboot to take effect.
SELINUX=enforcing
# Sets the default mode. Options: enforcing, permissive, disabled.
# 'enforcing' is the Fedora default and recommended for production.
SELINUXTYPE=targeted
# Defines the policy type. 'targeted' is the Fedora default.
# Do not change this unless you know the implications.
# Changing to 'minimum' or 'strict' breaks most desktop apps.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. The package manager will overwrite /usr/lib/ on updates, destroying your changes and potentially breaking the policy.
Edit /etc/selinux/config, not the runtime. Runtime changes vanish on reboot.
Common pitfalls and errors
The runtime mode and the persistent config can diverge. Running setenforce 0 changes the mode immediately but does not touch /etc/selinux/config. The next reboot restores the config value. Always edit /etc/selinux/config for permanent changes.
Here's how to toggle the mode at runtime for troubleshooting. Use this only when you need to test if SELinux is causing a failure during an active session.
setenforce 0
# Switches to Permissive mode at runtime.
# Does not change /etc/selinux/config.
# Reverts to config value on reboot.
# Use this to isolate SELinux denials temporarily.
Switching to Disabled requires a reboot. You cannot re-enable SELinux from the command line if the kernel booted with selinux=0. The error setenforce: SELinux is disabled means the kernel module is not loaded. You must change the config file and reboot.
If you see setenforce: SELinux is disabled, check the boot parameters. The kernel command line might contain selinux=0. Remove that parameter from GRUB and reboot. Fedora does not add selinux=0 by default. This usually happens if a user or script modified the boot options manually.
Another trap is assuming Permissive means SELinux is off. In Permissive mode, the kernel still evaluates the policy and generates audit messages. The logs can fill up quickly if you leave Permissive on for a long time. Use Permissive only for short troubleshooting windows or during initial migration.
Read the setroubleshoot summary. It often gives you the exact restorecon command you need.
When to use each tool
Use getenforce when you need a quick script-friendly check of the current mode.
Use sestatus when you need to audit the policy version or verify persistent configuration.
Use journalctl -t setroubleshoot when a service fails and you suspect an SELinux denial.
Use setenforce 0 only for temporary troubleshooting during an active session.
Edit /etc/selinux/config when you need the mode to survive a reboot.
Reboot the system when switching between Disabled and any other mode.