Disable Apport Service
Disables and stops the Apport automatic crash-reporting service so it cannot loosen fs.suid_dumpable at runtime.
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
Apport is Ubuntu's automatic crash-reporting daemon. At runtime it sets fs.suid_dumpable=2, which re-enables core dumps for setuid programs and silently reverts other hardening. Core dumps from privileged processes can leak passwords, keys, or other secrets to disk. Disabling Apport keeps fs.suid_dumpable hardening persistent and removes a service that collects and can exfiltrate sensitive crash data.
What Pavois checks
Pavois asks systemd for the effective state of apport.service via the service resource (backed by systemctl is-enabled / is-active), so it catches the unit being masked, statically enabled, or running regardless of what /etc/default/apport claims. A file-based check of /etc/default/apport would miss a unit that is enabled-but-disabled-in-config, or vice versa.
describe service('apport.service') do
it { should_not be_enabled }
it { should_not be_running }
endHow to verify it is applied
Confirm the unit is off:
systemctl is-enabled apport.service
systemctl is-active apport.service
Expect disabled (or masked) and inactive. Also verify the hardening it threatened stayed in place: sysctl fs.suid_dumpable should report fs.suid_dumpable = 0.
Inspect & investigate
Inspect the unit and its history with systemctl status apport.service and journalctl -u apport.service. Package state can be confirmed with dpkg -s apport. Crash files Apport would have produced live under /var/crash/.
Remediation
Pavois's harden plan acts on the service resource named apport: it runs disable (so the unit will not start at boot) then stop (so it is not running now). Applied with pavois harden apply. After it runs, the fs.suid_dumpable hardening can no longer be reverted by Apport at runtime.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | disable, stop |
|---|---|
| name | apport |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Misconfiguration risk: while Apport runs, privileged core dumps may be written and fs.suid_dumpable hardening silently reverts. Precautions: disabling Apport only removes automatic crash reporting/collection, it does not affect running applications. On developer or QA machines that rely on automatic crash capture, note that crashes will no longer be reported upstream; capture core dumps manually if needed. There is no lockout risk on servers.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.5.5 | direct | per OS, see the benchmark table | 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.