Restricting Linux Core Dumps Using limits.conf

This article explains how the Linux operating system uses the /etc/security/limits.conf configuration file to restrict core dumps, protecting sensitive runtime memory from unauthorized access. It covers the security implications of unrestricted core files, the distinction between hard and soft limits, the exact syntax required to enforce restrictions, and how to verify that your configuration is actively shielding the system.

The Security Risk of Core Dumps

A core dump is a copy of a process's memory space recorded to disk when that process terminates unexpectedly. While valuable for debugging, core dumps often contain plain-text passwords, cryptographic keys, personal identifying information, and other sensitive runtime data. If an attacker triggers an application crash or gains access to the filesystem, these files can be analyzed to extract confidential information. Restricting or disabling core dumps entirely is a fundamental security hardening practice on Linux systems.

How limits.conf Enforces Resource Controls

Linux enforces per-user and per-group resource usage through the Pluggable Authentication Module (PAM) subsystem, specifically via pam_limits.so. When a user logs in, PAM reads the configuration file located at /etc/security/limits.conf (as well as any .conf files inside /etc/security/limits.d/) to set process resource constraints, known as ulimits.

The configuration syntax in limits.conf uses four fields:

<domain>    <type>    <item>    <value>

• Domain: Specifies who the rule applies to. It can be a username, a group name (prefixed with @), or a wildcard (*) applying to all users.
• Type: Defines the enforcement level:
  • soft: The default limit enforced upon login. A user can increase this value up to the hard limit.
  • hard: The maximum ceiling set by the superuser. Non-root users cannot increase their limit beyond this value.
  • -: Enforces the specified value as both the soft and hard limit simultaneously.
• Item: The resource being restricted. For core dump file size, the item is core.
• Value: The maximum allowed size in 1024-byte blocks. Setting this to 0 prevents core dumps from being generated.

Disabling Core Dumps Globally

To completely prevent core dumps for all standard users, append the following lines to /etc/security/limits.conf:

*               hard    core            0
*               soft    core            0

Alternatively, use the combined hyphen notation:

*               -       core            0

To also restrict the root user, add an explicit entry, as wildcards do not always apply to root depending on the Linux distribution:

root            -       core            0

PAM Configuration Requirements

For limits.conf rules to take effect, the system's PAM authentication stack must load the pam_limits.so module during session creation.

Verify that the following line exists and is uncommented in your PAM session configuration files (typically /etc/pam.d/common-session, /etc/pam.d/login, or /etc/pam.d/sshd):

session required pam_limits.so

Without this module active in the PAM stack, the directives in limits.conf will be ignored upon login.

Verifying the Restriction

To confirm that the core dump restriction is active for a logged-in user, execute the built-in shell command:

ulimit -c

A return value of 0 confirms that core dump sizes are capped at zero blocks, effectively preventing the kernel from writing memory dumps to disk upon process failure. To check the hard limit specifically, run:

ulimit -Hc

If configured correctly, this command also returns 0, ensuring that the user cannot re-enable core dumps for their current session.

System Services Considerations

The limits.conf file primarily governs interactive user sessions and processes spawned via PAM. System daemons managed by systemd bypass PAM limits by default. To restrict core dumps system-wide for background services, configure DefaultLimitCORE=0 in /etc/systemd/system.conf and /etc/systemd/user.conf, or configure LimitCORE=0 within individual service unit files.