Disable Core Dumps for SUID programs
Sets fs.suid_dumpable=0 so setuid/setgid programs never write a core dump, preventing leakage of privileged memory contents.
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
A core dump captures the full memory image of a process at the moment it crashes. For a setuid/setgid program, which runs with privileges higher than the invoking user, that image can contain secrets, keys, or other privileged data the user should never see. Setting fs.suid_dumpable=0 forbids any setuid program from producing a core dump, preventing an attacker from deliberately crashing a privileged binary to harvest sensitive memory contents.
What Pavois checks
Pavois reads the live kernel value via the kernel_parameter resource (equivalent to sysctl fs.suid_dumpable), not /etc/sysctl.conf or any *.conf drop-in. A file may declare 0 while a later drop-in or a typo left the running value at 1 or 2; reading the running kernel reflects what setuid programs are actually allowed to do.
describe kernel_parameter('fs.suid_dumpable') do
its('value') { should cmp 0 }
end
describe command("grep -hsE '^[[:space:]]*fs.suid_dumpable[[:space:]]*=[[:space:]]*0([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run sysctl fs.suid_dumpable, expected output fs.suid_dumpable = 0.
Inspect & investigate
Read the current value with sysctl fs.suid_dumpable or cat /proc/sys/fs/suid_dumpable. If a setuid program crashes with dumping disabled, the kernel logs a coredump skipped style message visible via dmesg or journalctl -k, and any core handler such as systemd-coredump (journalctl -u systemd-coredump) will record the suppression.
Remediation
Pavois's harden plan sets the sysctl key fs.suid_dumpable to 0, persisting it to a managed drop-in and applying it live so the running kernel and future boots both use it. Applied with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | fs.suid_dumpable |
|---|---|
| resource | sysctl |
| value | 0 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Very low operational risk. The only loss is the ability to debug crashes of setuid binaries via core dumps, which is precisely the goal. If you must debug a specific privileged binary, temporarily raise the value to 2 (root-only, restricted dumps) in a controlled environment, then reset to 0. Reversible by changing the key.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R14 | direct | 2.0 | high |
| CIS | 1.5.3, 3.3.1.1, 1.5.4 | direct | per OS, see the benchmark table | high |
| NIST | SI-11(a), SI-11(b) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 3.3.1.1 | 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.