Ubuntu · Boot & system hardening

Disable core dumps

When it fails: Crashing programs can write their memory to disk. Core dumps can contain passwords, keys and personal data, and stay on disk long after the crash.

CB-UBU-BOOT-013lowactiveautomatedautomated fixprofile core

As released in v0.1.1 (beta). Current state.

Description

A core dump is a copy of the memory of a process written when it crashes. On Ubuntu, three 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/;
  • apport, installed by default, which registers itself as the core dump handler in kernel.core_pattern and stores crash reports, core dump included, in /var/crash/.

This control sets a hard core limit of 0 for every login session, and, with systemd-coredump, Storage=none and ProcessSizeMax=0. Apport is turned off by CB-UBU-BOOT-015.

Ubuntu sets a soft limit of 0 but leaves the hard limit unlimited (26.04 sets it explicitly 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.

A core dump handler declared in kernel.core_pattern (a line starting with |) receives the memory of the crashed process whatever its core limit: the kernel does not apply the limit to a pipe, and what is kept is up to the handler. This is why the session limit is not enough on Ubuntu while apport runs. Core dumps of setuid programs are covered separately by CB-UBU-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

Location/etc/security/limits.d/, /etc/systemd/coredump.conf.d/
DefaultSoft limit 0, hard limit unlimited
RecommendedHard limit 0; with systemd-coredump, Storage=none and ProcessSizeMax=0

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.
Restartusers must log in again
Disruptionnone

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-UBU-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-UBU-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

Mappings

FrameworkIDRelationNote
NIST SP 800-53 Rev. 55.1.1SI-11related

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

Threats mitigated

People and lifecycle

Authors
Verified2026-10-19 by Sn0wAlice on 20.04, Proxmox VM, Ubuntu 20.04 cloud image, kernel 5.4.0-216-generic, BIOS boot. Fails on a fresh install (hard core limit unlimited); fix writes limits.d; kept after reboot; systemd-coredump not installed, its checks report not_applicable.
Verified2026-10-19 by Sn0wAlice on 22.04, Proxmox VM, Ubuntu 22.04 cloud image, kernel 5.15.0-198-generic, BIOS boot. Fails on a fresh install (hard core limit unlimited); fix writes limits.d; kept after reboot; systemd-coredump not installed, its checks report not_applicable.
Verified2026-10-19 by Sn0wAlice on 24.04, Proxmox VM, Ubuntu 24.04 cloud image, kernel 6.8.0-147-generic, BIOS boot. Fails on a fresh install (hard core limit unlimited); fix writes limits.d; kept after reboot; systemd-coredump not installed, its checks report not_applicable.
Verified2026-10-19 by Sn0wAlice on 26.04, Proxmox VM, Ubuntu 26.04 cloud image, kernel 7.0.0-38-generic, BIOS boot. Fails on a fresh install (hard core limit unlimited); fix writes limits.d; kept after reboot; systemd-coredump not installed, its checks report not_applicable.
Introduced inv0.1.0
Created, updated2026-10-19, 2026-10-19
Translationsfr