Enable different security models
Requires the kernel to be built with CONFIG_SECURITY=y, the master switch that enables the Linux Security Modules (LSM) framework.
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.
Why this rule matters
This enables kernel security primitives required by the LSM framework. CONFIG_SECURITY is the master switch for Linux Security Modules; without it, SELinux, AppArmor, SMACK, Yama and the LSM hooks cannot exist, leaving the system with only classic DAC permissions and no mandatory-access-control layer to contain a compromised or over-privileged process.
What Pavois checks
Pavois reads the build options of the running kernel, grep '^CONFIG_SECURITY=' /boot/config-$(uname -r) or zcat /proc/config.gz, and requires y. Reading the live kernel's own config (keyed on uname -r) reflects exactly the booted kernel, which a package-name guess or generic file cannot.
describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_SECURITY=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_SECURITY=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_SECURITY=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep CONFIG_SECURITY). Expected output:
CONFIG_SECURITY=y
With LSM enabled you can also list the active modules with cat /sys/kernel/security/lsm (e.g. capability,yama,apparmor or ...,selinux).
Inspect & investigate
No routine log entry. The active LSMs are listed in /sys/kernel/security/lsm; MAC denials are logged by the module in use, AppArmor/SELinux events land in /var/log/audit/audit.log (type=AVC/type=APPARMOR) and in journalctl -k. Confirm the build flag with grep CONFIG_SECURITY /boot/config-$(uname -r).
Remediation
This is a kernel build-time option, so Pavois ships no automated harden step for it. It is satisfied by booting a distribution kernel compiled with CONFIG_SECURITY=y (true for all current Debian/Ubuntu/RHEL kernels, which ship AppArmor or SELinux); a custom kernel must be rebuilt. Activating an actual LSM (AppArmor/SELinux) is covered by separate rules.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | kernel_build |
|---|
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If absent, no mandatory-access-control module can load and the system relies solely on discretionary permissions, a major regression in containment. Precautions: simply enabling LSM support (via a compliant kernel) does not enforce any policy by itself, so it cannot break applications. Disruption only arises when you subsequently activate and enforce a specific module (SELinux/AppArmor) with a strict policy, test those policies in permissive/complain mode first to avoid blocking legitimate services.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R20 | direct | 2.0 | high |
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.