Parent: 2017 / 10
Prev: Signalfd, signals can be done right
Next: Back to Dynamic Libraries

Core dumps on CentOS 7

2017/10/17

Tags: [ GNU/Linux ]

I started by seeking on the Internet about this, I found out a lot of pointers to http://www.kibinlabs.com/re-enabling-core-dumps-redhat-7/ which is not available (at least for the moment). I had to figure out in other ways.

First off, the "non-systemd" way of having this is:

• Setting ulimits to allow for core-dumps

  • In CentOS this is in /etc/security/limits.conf (or /etc/security/limits.d if you want to avoid editing the `limits.conf file). To set the soft-limit on core creation to unlimited add this line:

    root       soft        core        unlimited
    

• Setting kernel configuration via sysctl (or /proc/sys/):

  • Useful configurations
    • kernel.core_pattern
    • kernel.core_use_pid
    • fs.suid_dumpable
  • Note: The set of valid template variables for kernel.core_pattern is usually available in the core(5) manpage;
  • Note: kernel.core_use_pid=1 attaches a .$pid to the core-file name. According to the documentation, this works only if the kernel.core_pattern path does not contain a %p;
  • Note: fs.suid_dumpable=2 has some security implications (read on).

In Systemd the rules are somewhat different:

• Systemd will not use /etc/security/limits.conf. The ulimit will be configured by editing /etc/systemd/system.conf and setting DefaultLimitCORE=infinity (or possibly something more sensible than infinity…)

• sysctl kernel.core_pattern='| /usr/lib/systemd/systemd-coredump %p %u %g %s %t %c %e'

  • This will invoke systemd-coredump, which will write the core dumps in /var/lib/systemd/coredump/ by default (according to this manual page);

Security implications of fs.suid_dumpable=2

This is a value which is suggested around the web as a magic, without mentioning the security risks associated to it.

To begin with, what does 2 mean? Quoting [https://www.kernel.org/doc/Documentation/sysctl/fs.txt][kern]

suid_dumpable:

This value can be used to query and set the core dump mode for setuid
or otherwise protected/tainted binaries. The modes are

0 - (default) - traditional behaviour. Any process which has changed
    privilege levels or is execute only will not be dumped.
1 - (debug) - all processes dump core when possible. The core dump is
    owned by the current user and no security is applied. This is
    intended for system debugging situations only. Ptrace is unchecked.
    This is insecure as it allows regular users to examine the memory
    contents of privileged processes.
2 - (suidsafe) - any binary which normally would not be dumped is dumped
    anyway, but only if the "core_pattern" kernel sysctl is set to
    either a pipe handler or a fully qualified path. (For more details
    on this limitation, see CVE-2006-2451.) This mode is appropriate
    when administrators are attempting to debug problems in a normal
    environment, and either have a core dump pipe handler that knows
    to treat privileged core dumps with care, or specific directory
    defined for catching core dumps. If a core dump happens without
    a pipe handler or fully qualifid path, a message will be emitted
    to syslog warning about the lack of a correct setting.

And why is it a risk? CVE-2006-2451 as mentioned in the kernel documentation.

Another interesting point, quoting https://serverfault.com/questions/56800/on-redhat-what-does-kernel-suid-dumpable-1-mean#56818:

So the idea is, if there are core dumps and a regular user can read them, they might find out privileged information. If the program is dumped well it had privileged information in memory, and the user can read the dump, they might find out that privileged information.