How to Disable SELinux on Fedora 44

SELinux usually stays invisible on Fedora until a container volume, custom service, or legacy application starts failing with permission errors that normal UNIX ownership cannot explain. The safest way to disable SELinux on Fedora is to test permissive mode first, then use a boot-time kernel argument only when you truly need SELinux off instead of temporarily relaxed.

Fedora Linux 44 and Fedora Linux 43 ship SELinux enabled and enforcing by default with the targeted policy. Fedora Linux 42 has aged out of Fedora’s current and previous release pair after Fedora 44’s release, so use these commands there only for recovery work before an upgrade to a supported Fedora release.

The commands target standard mutable Fedora systems such as Workstation and Server installs. Fedora Atomic desktops manage host changes differently, so use an Atomic-specific recovery plan before changing boot arguments on Silverblue, Kinoite, or another rpm-ostree based variant.

Check SELinux Status on Fedora

Start by checking whether SELinux is enabled, which policy is loaded, and whether the current boot is enforcing or permissive:

sestatus

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      35

Commands that change SELinux state need root privileges. If your account cannot use sudo yet, set that up first with the guide to create a sudo user on Fedora.

For a quick one-word mode check, use getenforce. A fresh Fedora installation normally returns Enforcing:

getenforce

Enforcing

SELinux Mode Comparison

Fedora uses the targeted SELinux policy by default. That policy confines selected system services while leaving many normal user processes unconfined. The mode determines whether policy violations are blocked, logged, or ignored:

Mode	What Fedora Does	Logging	Best Use
Enforcing	Blocks operations that violate policy	Logs AVC denials	Normal Fedora desktops, servers, and production systems
Permissive	Allows operations that would have been blocked	Logs would-be denials	Short troubleshooting windows and policy tuning
Disabled	Runs with no loaded SELinux policy, or fully disables SELinux when selinux=0 is used	No SELinux denial logging	Last-resort compatibility testing with a clear re-enable plan

Prefer permissive mode when you only need to prove whether SELinux is involved. Unlike disabled mode, permissive mode keeps labeling new files, so switching back to enforcing does not require a full filesystem relabel.

Temporarily Disable SELinux on Fedora

Temporary disablement means switching SELinux to permissive mode. Fedora keeps SELinux loaded and continues writing denial records, but it stops blocking the operation that triggered the problem. The change lasts until the next reboot unless you switch it back sooner.

This is the no-reboot option. You cannot fully disable SELinux on Fedora without a reboot because full disablement is decided during boot by the kernel command line or SELinux configuration state.

sudo setenforce 0

Confirm the live mode changed:

getenforce

Permissive

Switch SELinux back to enforcing when testing is finished:

sudo setenforce 1

If the same application works in permissive mode and fails in enforcing mode, review the SELinux denial instead of leaving the system relaxed. Fedora’s audit tools can show recent AVC messages:

sudo ausearch -m AVC,USER_AVC -ts recent

<no matches>

No matches means the current boot has no recent SELinux denial records for that query. If ausearch is missing on a minimal Fedora system, install the audit tools first:

sudo dnf install audit

Permanently Disable SELinux on Fedora

Use the boot-loader method for full SELinux disablement on current Fedora. Fedora’s own SELinux configuration file notes that SELINUX=disabled is deprecated for complete disablement because the kernel hooks may still run internally with no policy loaded. The selinux=0 kernel argument disables SELinux before policy loading starts.

Have console access or a tested remote recovery path before changing boot arguments. If this is a remote host, confirm SSH access on Fedora from a second session before rebooting.

Add selinux=0 to every installed kernel entry with grubby:

sudo grubby --update-kernel ALL --args="selinux=0"

Verify the argument was staged in the boot entries. Relevant output includes an args= line with selinux=0:

sudo grubby --info=ALL | grep -F "selinux=0"

args="ro rootflags=subvol=root rhgb quiet $tuned_params selinux=0"

Reboot only after the recovery path is ready:

sudo reboot

After the system starts again, confirm the running kernel received the argument:

grep -o "selinux=0" /proc/cmdline

selinux=0

Then verify SELinux is disabled from userspace:

sestatus

SELinux status:                 disabled

Config File Fallback for Disabled Mode

The older /etc/selinux/config method still makes userspace report SELinux as disabled after a reboot, but Fedora marks it as deprecated for full disablement. Use it only when you specifically want the policy not loaded and understand that selinux=0 is the cleaner full-disable path.

sudo sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

Confirm the file now requests disabled mode on the next boot:

grep -E '^SELINUX=' /etc/selinux/config

SELINUX=disabled

Reboot for the configuration file change to take effect:

sudo reboot

Disable SELinux Without Removing Packages

If you meant “remove SELinux” as in uninstalling the Fedora packages, do not remove selinux-policy-targeted, policycoreutils, or libselinux-utils. On Fedora 44, DNF protects the targeted policy package from removal because it is part of the base security policy stack.

A non-executing DNF transaction shows the protected-package result without removing anything:

sudo dnf remove --assumeno selinux-policy-targeted policycoreutils libselinux-utils

Relevant output includes:

Failed to resolve the transaction:
Problem: The operation would result in removing the following protected packages: selinux-policy-targeted

Use permissive mode for short troubleshooting, or use the selinux=0 boot argument when a full disable is required. Removing the package set is not the supported way to disable SELinux on Fedora.

Re-Enable SELinux on Fedora

Re-enabling from permissive mode is immediate. Re-enabling after disabled mode is more disruptive because files created while SELinux was off may lack correct labels. Plan for a longer reboot while Fedora relabels the filesystem.

If you only used permissive mode, switch back to enforcing:

sudo setenforce 1

If you used the selinux=0 kernel argument, remove it from the boot entries:

sudo grubby --update-kernel ALL --remove-args="selinux"

Set the SELinux configuration file back to enforcing:

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

Create the autorelabel marker before rebooting:

sudo touch /.autorelabel

The relabeling boot can take much longer than normal on large filesystems. Do not interrupt the process or force a shutdown while relabeling is running.

Reboot, then verify SELinux is active again:

sudo reboot

sestatus

SELinux status:                 enabled
Current mode:                   enforcing

Troubleshoot SELinux Issues on Fedora

setenforce Reports SELinux Is Disabled

setenforce can switch between enforcing and permissive only while SELinux is enabled. If SELinux is fully disabled, setenforce cannot bring it back without a boot change.

Check whether the running kernel was started with selinux=0:

grep -o "selinux=0" /proc/cmdline

If the command prints selinux=0, remove that argument with grubby, set SELINUX=enforcing, create /.autorelabel, and reboot through the re-enable sequence.

Config File Says Disabled but Kernel Argument Is Missing

On current Fedora, SELINUX=disabled in /etc/selinux/config can make userspace report disabled mode while the kernel was not started with the full-disable argument. Check both states when the distinction matters:

grep -E '^SELINUX=' /etc/selinux/config
grep -o "selinux=0" /proc/cmdline
sestatus

If the second command prints nothing, the booted kernel does not have selinux=0. Add the kernel argument with grubby when full disablement is the requirement.

Application Still Fails in Permissive Mode

If an application still fails after switching to permissive mode, SELinux is probably not the blocker. Verify the live mode first:

getenforce

Permissive

Then check system warnings and recent SELinux audit records:

sudo journalctl -p warning..alert -b
sudo ausearch -m AVC,USER_AVC -ts recent

For a named service, query that unit with journalctl -xeu before restarting it. For containers, review the Docker on Fedora setup and volume context choices. For network services, also verify Firewalld on Fedora rules before blaming SELinux.

Relabeling Takes a Long Time

A relabel after disabled mode can take minutes or much longer, depending on filesystem size, disk speed, and the number of files. During boot, Fedora may show a warning like this:

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.
***

Let the relabel finish. If the process is interrupted, boot into a recoverable state, recreate the marker, and reboot again:

sudo touch /.autorelabel
sudo reboot

System Fails to Boot After Re-Enabling SELinux

Boot into rescue mode or a live environment, mount the installed system if needed, and check the SELinux configuration file for an invalid value:

grep -E '^SELINUX=' /etc/selinux/config

Valid values are enforcing, permissive, and disabled. If the file is damaged, recreate a minimal default configuration and relabel on the next boot:

sudo tee /etc/selinux/config <<'EOF'
SELINUX=enforcing
SELINUXTYPE=targeted
EOF
sudo touch /.autorelabel

Reboot once the config is corrected. If the host is exposed to the network while SELinux is disabled or permissive, keep the firewall active and consider Fail2Ban with Firewalld on Fedora for repeated login attempts.

Conclusion

SELinux is now either temporarily permissive for troubleshooting or disabled at boot with a reversible kernel argument. Keep the disabled window as short as the compatibility problem allows, and restore enforcing mode with a filesystem relabel when the host is ready. For file-level scanning while you harden the system, ClamAV on Fedora is a useful next layer.