20.1 Set Enforcing and Permissive Modes for SELinux

20.1 Set Enforcing and Permissive Modes for SELinux

Quick Answer: Check mode with getenforce or sestatus. Temporary change: setenforce 1 (Enforcing) or setenforce 0 (Permissive). Permanent boot default: edit /etc/selinux/config (SELINUX=enforcing|permissive|disabled) and reboot. Prefer fixing labels and policy over leaving the system Disabled.

Why SELinux mode matters on EX200

Under Manage security, Red Hat expects you to set enforcing and permissive modes for SELinux. Lab language looks like:

• “Ensure SELinux is in enforcing mode.”
• “Temporarily set SELinux to permissive to diagnose a service failure.”
• “Configure the system so SELinux boots in enforcing mode.”
• “Report the current SELinux mode.”

You are graded on runtime mode and, when the task requires it, mode after reboot. Mode is only half of SELinux skill—contexts, booleans, and port labels appear in later sections—but if the mode is wrong, nothing else behaves as the grader expects.

What SELinux modes mean

In Enforcing, the kernel security module applies the loaded policy and denies unauthorized subject/object access. In Permissive, the same policy decisions are evaluated and logged (AVC messages), but the action is allowed. That makes Permissive excellent for proving “SELinux would have blocked this” without stranding a service mid-exam.

Disabled means SELinux is not active. Turning SELinux from Disabled back to Enforcing often triggers a full filesystem relabel on the next boot and can take significant time—dangerous under exam time pressure. Prefer Enforcing with correct contexts over disabling SELinux unless a task explicitly demands Disabled (rare for standard RHCSA flows).

Check current mode

getenforce
sestatus
# optional:
cat /etc/selinux/config | grep -E '^SELINUX='

getenforce prints a single word: Enforcing, Permissive, or Disabled—fastest check under time pressure.

sestatus shows richer detail:

• SELinux status (enabled/disabled)
• Current mode (runtime)
• Mode from config file (boot default)
• Policy name (commonly targeted on RHEL)
• Policy MLS status and other fields

sestatus
# Look for lines similar to:
# SELinux status:                 enabled
# Current mode:                   enforcing
# Mode from config file:          enforcing
# Policy from config file:        targeted

Exam habit: If current mode and config-file mode disagree, you have a temporary runtime override (from setenforce) or a config change that has not been rebooted yet. Resolve that mismatch intentionally.

Temporary mode: setenforce

sudo setenforce 1     # Enforcing
sudo setenforce 0     # Permissive
getenforce

You may also see symbolic arguments on some systems (Enforcing / Permissive), but 0 and 1 are universal and safe to memorize for RHEL:

Important limits:

1. setenforce does not survive reboot. Boot mode comes from /etc/selinux/config (and related boot options).
2. setenforce cannot switch from Disabled to Enforcing. If SELinux is fully disabled, you must edit the config and reboot (often with a relabel).
3. Switching Enforcing ↔ Permissive with setenforce is immediate and does not require a reboot.

Diagnostic pattern with Permissive

When a service fails and you suspect SELinux:

getenforce
sudo setenforce 0
# reproduce the service start / access that failed
# check logs if needed, then restore enforcing when done diagnosing
sudo setenforce 1
getenforce

If the problem disappears in Permissive, SELinux was involved. The durable fix is usually labels, booleans, or port labels—not leaving the host in Permissive forever. Chapter 21 covers booleans and port labels; this section owns mode control.

Persistent mode: /etc/selinux/config

sudo cat /etc/selinux/config

Key directives (simplified):

SELINUX=enforcing
SELINUXTYPE=targeted

Edit carefully:

sudo grep '^SELINUX=' /etc/selinux/config
# Example: force enforcing at next boot
sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
grep '^SELINUX=' /etc/selinux/config

Or use a text editor (vim, nano) and change only the SELINUX= line. Do not set SELINUXTYPE to experimental values on the exam unless the task says so.

Reboot is required for config-file mode

sudo grep '^SELINUX=' /etc/selinux/config
sudo reboot
# after reboot:
getenforce
sestatus

Until reboot:

• getenforce still reflects the current runtime mode.
• sestatus may show “Mode from config file” already updated while “Current mode” still shows the old runtime value if you also used setenforce differently.

Exam workflow for permanent Enforcing:

1. Set SELINUX=enforcing in /etc/selinux/config.
2. Optionally setenforce 1 so runtime matches now without waiting for reboot.
3. Verify both runtime and config.
4. Reboot if the lab requires proving persistence (or if you changed Disabled ↔ enabled).

getenforce / setenforce / config map

Disabled and the relabel trap

If SELinux was Disabled and you set SELINUX=enforcing (or permissive) again:

• On next boot the system may schedule a relabel of the filesystem so labels match policy.
• Relabel can be forced with a /.autorelabel file and reboot (advanced recovery pattern).

# Awareness only — full relabel costs time:
# sudo touch /.autorelabel && sudo reboot

On EX200, do not disable SELinux as a shortcut to make Apache/NFS/SSH “just work.” Fix the label or boolean instead. If a previous admin left SELinux disabled, re-enabling is a multi-step recovery—budget time carefully.

Logs and evidence of mode-related denials

While diagnosing (often in Permissive):

sudo ausearch -m avc -ts recent 2>/dev/null | tail
sudo journalctl -t setroubleshoot --since "10 min ago" 2>/dev/null | tail
sudo tail -n 50 /var/log/audit/audit.log

Exact tooling availability can vary, but audit AVC messages are the classic SELinux denial trail. Mode itself does not “write a special config” for denials—policy and labels do. Mode only decides whether denials are enforced.

Verification checklist

getenforce
sestatus
grep -E '^SELINUX=|^SELINUXTYPE=' /etc/selinux/config

Confirm:

1. Runtime mode matches the task (Enforcing is the common end state).
2. Config file matches if the task says “on boot,” “persistently,” or “after reboot.”
3. You did not leave the host in Permissive after a diagnostic detour unless that was required.

Exam workflows

Workflow A — Prove current mode

getenforce
sestatus | egrep 'status|Current mode|Mode from config|Policy from config'

Workflow B — Temporary Permissive, then back to Enforcing

getenforce
sudo setenforce 0
getenforce
# ... diagnose or complete a step that required permissive ...
sudo setenforce 1
getenforce

Workflow C — Persistent Enforcing (runtime + boot)

sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
sudo setenforce 1
getenforce
grep '^SELINUX=' /etc/selinux/config
sestatus

Workflow D — Boot Permissive by policy of the task

sudo sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config
sudo setenforce 0
getenforce
grep '^SELINUX=' /etc/selinux/config
# reboot if required to prove boot mode

Workflow E — Detect mismatch

echo "runtime: $(getenforce)"
echo -n "config: "; grep '^SELINUX=' /etc/selinux/config
sestatus

If runtime is Permissive but config is enforcing, someone ran setenforce 0—or you did. Decide whether to restore Enforcing now.

Common traps

1. Editing /etc/selinux/config only and assuming runtime changed without setenforce or reboot.
2. Using only setenforce 1 when the task requires the boot default to be Enforcing—config file still says permissive/disabled.
3. Leaving Permissive after troubleshooting so denials never block (and the grader may still expect Enforcing).
4. Disabling SELinux to “fix” a web root or home directory path—wrong skill for EX200; use contexts (Section 20.3).
5. Expecting setenforce to enable SELinux when status is Disabled—needs config + reboot (and often relabel).
6. Changing SELINUXTYPE accidentally while editing the file.
7. Not verifying with getenforce after every mode change.
8. Confusing mode with context or boolean—mode is global; contexts are per object/process.
9. Forgetting that Permissive still loads policy and still logs denials—useful for diagnosis.
10. Burning exam time on a full relabel path that was never required.

Relationship to other sections

Services that fail only under Enforcing usually need correct labels or booleans, not a permanent mode demotion.

Section checkpoint

You should read the current mode with getenforce and sestatus, switch runtime Enforcing/Permissive with setenforce 1|0, set the boot default in /etc/selinux/config, understand that config changes need reboot while setenforce is immediate and temporary, avoid casual Disabled, use Permissive for diagnosis, and leave the system in the mode the task requires—almost always Enforcing with a matching config on RHEL 10 for EX200.