Warn on W+X mappings found at boot
Requires the kernel to be built with CONFIG_DEBUG_WX=y, which warns at boot when any memory page is mapped both writable and executable.
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 is useful for discovering cases where the kernel is leaving W+X mappings after applying NX, as such mappings are a security risk. Note that even if the check fails, your kernel is possibly still fine, as W+X mappings are not a security hole in themselves, what they do is that they make the exploitation of other unfixed kernel bugs easier.
What Pavois checks
Pavois reads the effective build flag of the running kernel via /boot/config-$(uname -r) or /proc/config.gz, keyed on $(uname -r), so it reflects the actually booted image rather than a stray .config a fixed-path file scan might match.
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_DEBUG_WX=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_DEBUG_WX=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_DEBUG_WX=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep '^CONFIG_DEBUG_WX='). Expected output: CONFIG_DEBUG_WX=y. Absent or # CONFIG_DEBUG_WX is not set is a failure.
Inspect & investigate
At boot, if W+X mappings remain, the kernel prints a count and details to the ring buffer: dmesg | grep -i 'W+X\|wx' or journalctl -k | grep -i 'W+X'. A clean system shows Checked W+X mappings: passed. Confirm the flag with zcat /proc/config.gz | grep DEBUG_WX.
Remediation
No automated remediation is shipped: a kernel build option cannot be set by editing a file. Apply it manually by installing and booting a kernel compiled with CONFIG_DEBUG_WX=y.
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
A page that is simultaneously writable and executable (W+X) lets an attacker who can write into it then run that data as code, the foundation of many exploitation techniques. A correctly hardened kernel applies W^X (write-XOR-execute) so no page is both. CONFIG_DEBUG_WX does not by itself remove W+X pages; it detects and reports them at boot so leftover violations are caught. Missing it means W+X regressions go unnoticed, weakening the defense against code-injection attacks. This is a build-time option, set only by booting a kernel compiled with it. Precautions: stock kernels may not enable it; moving to a hardened kernel changes module ABI, so validate that all drivers load and review dmesg for new W+X warnings (some out-of-tree modules legitimately trip it) before treating production as healthy. No reboot risk beyond a normal kernel swap.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R15 | 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.