Disable core dumps

Description

A core dump is a copy of the memory of a process written when it crashes. On Debian, two mechanisms decide whether one is written:

• the core resource limit of the process, set for login sessions by pam_limits from /etc/security/limits.conf and /etc/security/limits.d/;
• when the systemd-coredump package is installed, its configuration (/etc/systemd/coredump.conf and /etc/systemd/coredump.conf.d/), which stores the dumps in /var/lib/systemd/coredump/.

This control sets a hard core limit of 0 for every login session, and, with systemd-coredump, Storage=none and ProcessSizeMax=0.

Debian 13 sets a soft limit of 0 but a hard limit of infinity in /etc/security/limits.d/10-coredump-debian.conf, so any user can turn dumps back on with ulimit -c. The file written by the fix sorts after it and wins. Core dumps of setuid programs are covered separately by CB-DEB-BOOT-005.

Rationale

The memory of a crashed process holds whatever it was working on: passwords typed by a user, session tokens, private keys, documents. Core files are often readable by more people than the original process, are collected by support tools, and are rarely cleaned up.

Impact

Crashes cannot be analysed from a core dump. When a crash must be debugged, raise the limit for that one session (ulimit -c unlimited after removing the hard limit) on a test system.

Setting

Audit

1. Run su -s /bin/sh nobody -c 'ulimit -Hc'. It must print 0.
2. If systemd-coredump is installed, run systemd-analyze cat-config systemd/coredump.conf: the last Storage= must be none and the last ProcessSizeMax= must be 0.

Automated: every check must pass. Scanners report each check by its id.

session-limit

Hard core size limit applied to a login session.

script: |
  v=$(su -s /bin/sh nobody -c 'ulimit -Hc' 2>/dev/null) || exit 3
  echo "hard core limit: $v"
  [ "$v" = 0 ]

coredump-storage

Effective Storage= of systemd-coredump.

script: |
  v=$(systemd-analyze cat-config systemd/coredump.conf 2>/dev/null | sed -n 's/^[[:space:]]*Storage=//p' | tail -n 1)
  echo "Storage=${v:-external (default)}"
  [ "$v" = none ]

coredump-size

Effective ProcessSizeMax= of systemd-coredump.

script: |
  v=$(systemd-analyze cat-config systemd/coredump.conf 2>/dev/null | sed -n 's/^[[:space:]]*ProcessSizeMax=//p' | tail -n 1)
  echo "ProcessSizeMax=${v:-default}"
  [ "$v" = 0 ]

Remediation

1. Create /etc/security/limits.d/60-cirsec.conf with:

   *    hard core 0
   root hard core 0
   

2. If systemd-coredump is installed, create /etc/systemd/coredump.conf.d/60-cirsec.conf with:

   [Coredump]
   Storage=none
   ProcessSizeMax=0
   

3. Log out and back in for the session limit to apply.

Rollback

Delete the two files. New sessions get the previous limits back.

session-limit

f=/etc/security/limits.d/60-cirsec.conf
cb_backup "$f"
printf '%s\n' '# Written by CIRSEC Baselines CB-DEB-BOOT-013' '*    hard core 0' 'root hard core 0' >"$f"
chmod 644 "$f"

coredump-conf

f=/etc/systemd/coredump.conf.d/60-cirsec.conf
cb_backup "$f"
mkdir -p /etc/systemd/coredump.conf.d
printf '%s\n' '# Written by CIRSEC Baselines CB-DEB-BOOT-013' '[Coredump]' 'Storage=none' 'ProcessSizeMax=0' >"$f"
chmod 644 "$f"

Handwritten code reads parameters from CB_<NAME> environment variables. Each release turns these fixes into remediate.sh and an Ansible role per profile: dry run by default, a fix runs only when its check fails.

References

• limits.conf(5), Debian manual pages Debian, vendor-doc, accessed 2026-10-18
• coredump.conf(5), Debian manual pages Debian, vendor-doc, accessed 2026-10-18

Mappings

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

Related controls

• related CB-DEB-BOOT-005 Disable core dumps of setuid programs

People and lifecycle