WHAT YOU NEED TO KNOW
System administrators must understand how to disable core dump backtraces and why this operational control is essential for server defense: crash dumps routinely write plain-text credentials, private keys, and session tokens to local disk storage.
- Setting ProcessSizeMax=0 in /etc/systemd/coredump.conf completely suppresses backtrace processing and stops local storage allocation for crash artifacts.
- Unrestricted core dumps cause severe core dump memory exposure, writing 100% of an application’s volatile RAM to unencrypted storage files upon execution failure.
- Applying a ulimit core dump restriction of 0 in /etc/security/limits.conf prevents unprivileged user processes from generating binary state files on disk.
- Aligns host configurations with MITRE ATT&CK technique T1005 mitigation standards by denying post-exploitation memory access to unprivileged local actors.
Disabling crash logging halts localized automated debugging, so administrators should establish temporary override procedures for staging environments when active memory inspection is required.
What Are Linux Core Dumps and Backtraces?
A core dump is an uncompressed file containing the complete memory footprint and register states of a process at the precise millisecond it encounters an unhandled signal or crash. A backtrace is an extracted call stack parsed from that memory image that maps the sequence of function execution leading directly to the program fault.
When a program terminates abnormally due to a segmentation fault or buffer overflow, the Linux kernel captures the memory contents assigned to that process ID. Debugging utilities such as gdb read these binary artifacts to reassemble execution pointers, stack frames, and parameter state values for developer analysis.
In modern distributions managed by systemd, systemd-coredump intercepts kernel dump events through system sockets. As documented in current Linux system administration standards verified as of 2026, the utility processes the raw kernel stream, writes the binary crash image to /var/lib/systemd/coredump/, and automatically parses the stack frame to store an inline backtrace inside journalctl.
Disable Core Dump Backtraces and Why: Security Risks Explained
Disabling core dump generation and automated stack parsing prevents unauthorized users and malicious software from extracting sensitive runtime data directly from persistent storage files. Leaving crash dumps enabled exposes production environments to severe post-exploitation memory harvesting techniques and operational instability.
- Exposure of Sensitive RAM Artifacts: Core dump files mirror active process memory, writing plaintext passwords, private TLS keys, API authorization tokens, and database connection strings directly to persistent storage.
- Exploit Development Intelligence: Automated backtrace reports expose internal stack pointers, shared library memory addresses, and program structure, giving attackers precise dynamic data to craft return-oriented programming exploits.
- Compliance and Governance Violations: Storing unencrypted volatile memory snapshots on disk violates regulatory frameworks such as PCI-DSS 4.0 and CIS Benchmarks, which mandate strict controls against unencrypted lingering credentials.
- Storage Exhaustion Denial of Service: Recurring process crashes under heavy application loads can rapidly write gigabytes of binary dump files, filling root storage partitions and causing host outages.
How to Disable Core Dumps in Linux
System administrators can eliminate core dumps across Linux distributions by restricting kernel limits, disabling core piping in sysctl parameters, or configuring systemd services to reject crash image processing. Combining these configuration layers creates a comprehensive strategy for linux core dump hardening across system architectures.
Disabling Core Dumps via limits.conf and sysctl
System-wide limits enforced through PAM modules restrict individual process memory allocation for core files to zero bytes. Updating kernel configuration parameters through sysctl further prevents the system kernel from redirecting process crashes to debugging helper scripts.
To apply process-level restrictions across user shell sessions and background daemons, edit /etc/security/limits.conf or create a dedicated drop-in file at /etc/security/limits.d/50-coredump.conf.
- Add hard core size restriction:
* hard core 0 - Add soft core size restriction:
* soft core 0 - Disable kernel core dump pattern piping in /etc/sysctl.d/50-coredump.conf:
fs.suid_dumpable = 0andkernel.core_pattern = |/bin/false - Apply live kernel parameters immediately:
sysctl -p /etc/sysctl.d/50-coredump.conf
Disabling Core Dumps in systemd Environments
Distributions utilizing systemd require direct configuration inside /etc/systemd/coredump.conf or drop-in files under /etc/systemd/coredump.conf.d/ to stop automatic stack trace parsing and storage. Setting size execution thresholds to zero disables backtrace compilation completely.
In systemd-managed architectures, the process manager intercepts crash events before standard POSIX user limits evaluate the process state. Administrators must update systemd settings to reject incoming binary dumps from the kernel pipe.
Create a drop-in file at /etc/systemd/coredump.conf.d/60-disable-coredump.conf containing the [Coredump] section header. Define Storage=none and ProcessSizeMax=0 within this block. Setting ProcessSizeMax=0 ensures systemd discards the memory payload without generating an inline backtrace log, while Storage=none prevents disk allocation. Reload daemon settings using systemctl daemon-reload to enforce the rules across running host services.
How to Verify Core Dumps Are Disabled
System administrators verify core dump suppression by checking active shell limit configurations and triggering controlled signal crashes against isolated test processes. Verifying that no binary files or stack trace logs appear in system storage confirms successful system hardening.
Execute ulimit -c inside an active user session to confirm the shell reports a maximum core file size limit of 0. According to guidelines published by the Cybersecurity and Infrastructure Security Agency (CISA), verifying operational security settings via live assertions ensures configuration parameters were parsed correctly by system utilities.
Query running system parameters using sysctl fs.suid_dumpable to confirm set values equal 0. Next, test system handling safely by launching a disposable process such as sleep 100 & and issuing a segmentation kill signal using kill -s SIGSEGV $!. Inspect /var/lib/systemd/coredump/ and execute journalctl -u systemd-coredump to confirm that no memory files or parsed call stack logs were generated.
How to Re-enable Core Dumps for Troubleshooting
System administrators temporarily re-enable core dump logging in development environments by adjusting process resource limits and raising systemd processing thresholds. Reverting these changes immediately after completing diagnostic traces protects host security.
When diagnosing complex application failures, software developers require temporary access to detailed call stack traces and variables. Controlled debugging sessions permit temporary core generation without permanently compromising production security baselines.
- Increase current shell limits temporarily:
ulimit -c unlimited - Configure temporary systemd overrides in /etc/systemd/coredump.conf.d/debug.conf: set
Storage=externalandProcessSizeMax=2G - Reload systemd logging services:
systemctl daemon-reload - Inspect collected memory files using analysis tools:
gdb /path/to/binary /var/lib/systemd/coredump/corefile - Restore security baselines: remove the debugging override file and execute
systemctl daemon-reloadimmediately upon completing fault triage.