Disable acquiring, saving, and processing core dumps
Ensures systemd-coredump.service is disabled and not running so application core dumps are not acquired, saved, or processed.
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.
Why this rule matters
A core dump is a memory image captured when the OS terminates a crashing application. That image can contain highly sensitive data, passwords, encryption keys, tokens, personal data, and is generally useful only to developers debugging the program. Leaving systemd-coredump active means such memory snapshots are written to disk where they can be read by an attacker or leak secrets. Disabling core dump collection reduces the exposure of in-memory secrets and removes a vector for information disclosure.
What Pavois checks
Pavois reads the effective unit state with service('systemd-coredump.service') (systemctl is-enabled / is-active). On most systems this is socket-activated (systemd-coredump.socket), so the check confirms it will not be triggered. This is more reliable than grepping /etc/sysctl.d/ for kernel.core_pattern, because the effective state accounts for masking and drop-in overrides under /etc/systemd/system/.
describe command('systemd-analyze cat-config systemd/coredump.conf 2>/dev/null | grep -iE "^[[:space:]]*Storage[[:space:]]*=" | tail -1') do
its('stdout') { should match(/=\s*none/i) }
endHow to verify it is applied
Run systemctl is-enabled systemd-coredump.service (expect disabled, masked, or static) and systemctl is-active systemd-coredump.service (expect inactive or failed-free). You can further confirm the kernel will not invoke it with sysctl kernel.core_pattern (it should not point to systemd-coredump).
Inspect & investigate
Check journalctl -u systemd-coredump.service and coredumpctl list, when disabled, no new dumps should appear after a crash. The effective kernel routing is shown by sysctl kernel.core_pattern; an entry mentioning systemd-coredump means dumps are still being captured.
Remediation
Pavois's harden plan acts on the service resource named systemd-coredump: it runs disable (so it is not triggered at boot) and stop (so it is not running now). It is applied with pavois harden apply. For complete suppression, pair this with a kernel.core_pattern / fs.suid_dumpable=0 sysctl policy and limits in /etc/security/limits.conf.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| content | [Coredump] Storage=none ProcessSizeMax=0 |
|---|---|
| group | root |
| mode | 0644 |
| owner | root |
| path | /etc/systemd/coredump.conf.d/99-pavois.conf |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Disabling core dump processing means crashes no longer produce dumps for coredumpctl, which removes a developer debugging aid. This is acceptable on production/security-hardened hosts but can hinder root-cause analysis of recurring crashes. Precautions: if you actively debug a service, re-enable temporarily, capture the dump on a controlled host, then disable again, and never store dumps containing secrets on shared or backed-up storage.