← All rules
SOCLE-CLD-KRN-068// Kernel buildmediumeffective runtime

Disable mutable hooks

Requires the kernel not to be built with CONFIG_SECURITY_WRITABLE_HOOKS=y, so the LSM hook table stays read-only after init.

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.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

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

If CONFIG_SECURITY_WRITABLE_HOOKS is enabled, then hooks can be loaded at runtime and being able to manipulate hooks is a way to bypass all LSMs. When the LSM hook table is kept read-only (CONFIG_SECURITY_WRITABLE_HOOKS not set, paired with __ro_after_init), an attacker who gains a kernel write primitive cannot overwrite the security hooks to silently neutralize SELinux/AppArmor, removing a powerful tampering avenue that would defeat every mandatory-access-control protection at once.

What Pavois checks

Pavois reads the build options of the running kernel, grep '^CONFIG_SECURITY_WRITABLE_HOOKS=' /boot/config-$(uname -r) or zcat /proc/config.gz, and requires that the value is not y (the symbol is normally absent). 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_WRITABLE_HOOKS=|PAVOIS_NO_KERNEL_CONFIG)'") do
  its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
  its('stdout') { should_not match(/^CONFIG_SECURITY_WRITABLE_HOOKS=y$/) }
end

How to verify it is applied

Run grep '^CONFIG_SECURITY_WRITABLE_HOOKS=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep CONFIG_SECURITY_WRITABLE_HOOKS). Expected result: no output, or a line such as # CONFIG_SECURITY_WRITABLE_HOOKS is not set, anything other than CONFIG_SECURITY_WRITABLE_HOOKS=y is compliant.

Inspect & investigate

No routine log entry. Confirm directly via grep CONFIG_SECURITY_WRITABLE_HOOKS /boot/config-$(uname -r). The active LSMs whose hooks this protects are listed in /sys/kernel/security/lsm.

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 built without CONFIG_SECURITY_WRITABLE_HOOKS (the default for all current Debian/Ubuntu/RHEL kernels); a custom kernel that enables it must be reconfigured and rebuilt.

Pavois applies this with its own harden engine, the plan below, not a shell script:

resourcekernel_build
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

If enabled, a kernel write primitive can be escalated to patch the LSM hook table and disable all mandatory access control silently. Precautions: keeping hooks read-only is the safe default and breaks nothing, only out-of-tree LSMs or experimental modules that need to register hooks at runtime would require writable hooks, which is itself a security anti-pattern. Removing the option simply means using a stock kernel; no service impact or lockout risk.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R20direct2.0high

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.

Sources & references

Official standards

ANSSI-BP-028 (2.0) ↗