Disable support for /proc/kcore
Requires the running kernel to be built without CONFIG_PROC_KCORE so the /proc/kcore view of live kernel memory does not exist.
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
/proc/kcore is a pseudo-file that exposes the running kernel's memory as an ELF core image. To a privileged attacker (or a tool aiding privilege escalation) it is a map of kernel structures and a way to read live kernel memory, helping defeat KASLR and discover attack vectors. Building the kernel without CONFIG_PROC_KCORE removes this introspection surface entirely. This is a defence-in-depth, low-severity hardening: it shrinks what an attacker who already has elevated rights can learn.
What Pavois checks
Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r), falling back to /proc/config.gz, so the result reflects the booted kernel. Unlike the other rules in this domain, this check asserts the option is not set to y (should_not match), because /proc/kcore should be absent.
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_PROC_KCORE=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should_not match(/^CONFIG_PROC_KCORE=y$/) }
endHow to verify it is applied
Run grep '^CONFIG_PROC_KCORE=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep '^CONFIG_PROC_KCORE='). The line must be absent or read CONFIG_PROC_KCORE=n, it must not be =y. Also confirm the file is gone: ls -l /proc/kcore should report No such file or directory.
Inspect & investigate
There is no event log for this static surface; confirm by presence/absence of the file itself: ls -l /proc/kcore. Access attempts to /proc/kcore by a process can be caught with an auditd watch (auditctl -w /proc/kcore -p r -k kcore) and would then appear in /var/log/audit/audit.log under key="kcore".
Remediation
No automated remediation: CONFIG_PROC_KCORE is a kernel build-time option and cannot be unset at runtime. Most distribution kernels enable it, so compliance generally requires a custom-built kernel with the option disabled. As a runtime mitigation you can restrict access (/proc/kcore is already root-only, mode 0400) or audit reads. Apply manually; pavois harden apply cannot change a compiled-in setting.
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
Leaving /proc/kcore available gives a privileged attacker an easy way to read kernel memory and undermine KASLR, but it is only reachable by root, hence the low severity. The practical cost of removing it is that kernel debugging and live-memory forensics tools (crash, gdb against kcore, some perf/eBPF introspection) lose a data source. Precaution: only disable it on production hosts that do not need live kernel debugging; keep it on dedicated debug/analysis systems. There is no lockout or availability risk.
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.