On a RHEL host, what is the difference between SELinux running in enforcing mode, permissive mode, and being disabled, and why is `setenforce 0` not the same as setting SELINUX=disabled in /etc/selinux/config?

## What SELinux is, in one paragraph SELinux is a Linux Security Module: kernel code that sits on the syscall paths and answers a second question after the classic owner/group/mode check has already said yes. That second question is asked against a loaded *policy* — a compiled ruleset that says which process domains may perform which operations on which object types. Because the policy is loaded into the kernel, its state is a property of the running system, and that state is exactly what the three modes describe. ## The three states **Enforcing.** The policy is loaded and consulted, and any access it does not allow is refused. The calling program receives an ordinary error — usually `EACCES` — with no hint that SELinux was involved, and the kernel writes an AVC (Access Vector Cache) denial record to the audit log. This is the only mode that provides containment. **Permissive.** The policy is loaded and evaluated, denials are logged in exactly the same way, but the operation proceeds. Nothing is protected. Its value is diagnostic and it is more useful than it first looks: in enforcing mode a program often dies at the *first* denial, so you only ever see one. In permissive mode the program runs to completion and the log accumulates the *whole* set of accesses the policy is missing, which is what you need before you write a fix. **Disabled.** No policy is loaded. No checks happen — and, the part people forget, the labelling machinery is not running either. Newly created files get no SELinux label, and files whose labels would normally have been maintained drift out of date. That is why disabling is not a free, reversible experiment. ## Runtime toggle versus boot-time configuration `setenforce 0` (permissive) and `setenforce 1` (enforcing) flip the running kernel between the two *loaded-policy* states. They are runtime-only, they vanish on reboot, and they cannot rescue a disabled system: with no policy loaded there is nothing to enforce. The boot-time state comes from `/etc/selinux/config`: ``` SELINUX=enforcing SELINUXTYPE=targeted ``` `SELINUX=` takes `enforcing`, `permissive` or `disabled`; `SELINUXTYPE=` names the policy to load, and `targeted` is the default on RHEL and Fedora — it confines listed system services and leaves ordinary user sessions in a largely unrestricted domain. The kernel command line can also override this: `enforcing=0` boots permissive, and `selinux=0` turns the subsystem off entirely. On RHEL 9, turning SELinux off through the config file is deprecated and the supported way to disable it is the `selinux=0` kernel parameter. Inspect the result with `getenforce` (prints one word) or `sestatus` (prints current mode, mode from the config file, and the loaded policy). ## Coming back from disabled Because labels were not maintained while the policy was unloaded, re-enabling straight into enforcing usually produces a flood of denials from mislabelled files. The standard procedure is to set the config back to `enforcing` (or `permissive` for a first pass), create the relabel flag and reboot: ```bash touch /.autorelabel reboot ``` The init system sees the flag, relabels every filesystem against the policy's default-context database, removes the flag and reboots again. On a large filesystem this takes real time, which is the practical argument against ever disabling SELinux on a machine you intend to keep. ## Using permissive without going global Whole-machine permissive removes protection from every confined service just to debug one. SELinux supports *permissive domains* instead: `semanage permissive -a httpd_t` makes that single domain behave permissively while everything else stays enforcing, and `semanage permissive -d httpd_t` reverses it. That is the professional version of `setenforce 0`. ## The mistakes that show up in interviews The first is treating permissive as "off" — it is not, and a system left permissive gives you audit noise with no containment. The second is answering a denial with `setenforce 0` and calling it fixed; that is disabling the alarm, and it will come back at the next reboot or, worse, silently stay off. The third is assuming disabling and re-enabling is symmetric, when the asymmetry is the relabel. The fourth is forgetting that a denial surfaces to the application as a generic permission error, so the application's own log rarely says SELinux anywhere — you have to go to the audit log to see it.