Ensure SELinux State is Enforcing
SELinux must run in enforcing mode: policy denials are actually blocked, not merely logged as they are in permissive. Pavois checks both the running state (getenforce returns Enforcing) and the persisted intent (SELINUX=enforcing in /etc/selinux/config). RHEL family only.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
What Pavois checks
getenforce returns the effective kernel state, which is the only thing that decides whether a denial blocks or merely logs. /etc/selinux/config expresses the intent at boot and nothing more: it can be overridden from the kernel command line (selinux=0, enforcing=0), so a host can boot Permissive or Disabled while its config file says enforcing. Reading only that file would report a host with SELinux effectively off as compliant. Pavois therefore requires both: the running state and the persisted setting, so the mode also survives a reboot.
describe command('getenforce') do
its('stdout.strip') { should cmp 'Enforcing' }
end
describe file('/etc/selinux/config') do
its('content') { should match(/^SELINUX=enforcing/) }
endHow to verify it is applied
Confirm the running mode, the persisted mode, and that nothing on the kernel command line is disabling SELinux:
getenforce
# Enforcing
sestatus | grep -E 'SELinux status|Current mode|Policy from config'
grep ^SELINUX= /etc/selinux/config
# SELINUX=enforcing
grep -o 'selinux=0\|enforcing=0' /proc/cmdline
# (no output expected)
Inspect & investigate
Every access a policy refuses is written to /var/log/audit/audit.log as an AVC record (type=AVC ... denied { ... } scontext=... tcontext=...); with auditd stopped, the same lines land in the kernel log (journalctl -k, dmesg). Grep the raw audit log for avc: rather than relying on ausearch, which is known to return false "no matches". In permissive mode those very same AVC records are produced without blocking anything: that is how you inventory what enforcing will break, and what audit2why / audit2allow consume to explain a denial or propose a policy module.
Remediation
The Pavois plan persists the mode first, then raises the live state, and it deliberately refuses the dangerous shortcut. It rewrites /etc/selinux/config to SELINUX=enforcing / SELINUXTYPE=targeted, then runs setenforce 1 only if the current state is Permissive. If SELinux booted Disabled, Pavois never calls setenforce (the command errors out, and switching an unlabelled filesystem straight to enforcing can lock everyone out): it creates /.autorelabel instead, so the next reboot relabels the whole filesystem and brings the host up enforcing. That reboot remains the administrator's decision. Every step is gated on /etc/selinux/config existing, so the whole block is a no-op on Debian and Ubuntu.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | selinux_state |
|---|---|
| state | enforcing |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Enforcing on a system that has never been labelled can prevent it from booting. When SELinux has run Disabled, files created since then carry no security context: switching to enforcing without a full filesystem relabel leaves init unable to transition domains, and services (starting with sshd and the login stack) get denied. That is why Pavois schedules /.autorelabel instead of forcing the state. Before applying:
- From
Disabled: expect the relabel plus a reboot, and expect it to take time (minutes, much longer on a large filesystem, with the machine unavailable meanwhile). Have console access; never rely on SSH alone. - From
Permissive: this is the safe path, but only once the denial backlog is empty. Inventory the AVC records in/var/log/audit/audit.logand fix their causes (a wrong label on a non-standard data directory, a service listening on a non-standard port that needssemanage port, a boolean to flip) before enforcing. Anything still denied in the log will break the moment enforcing kicks in. - Check the kernel command line: a leftover
selinux=0orenforcing=0silently defeats the change at the next boot.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R37 | direct | 2.0 | high |
| CIS | 1.3.1.5 | direct | per OS, see the benchmark table | high |
| NIST | AC-3 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 1.2.6 | supporting | 4.0.1 | medium |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.