Core dumps on CentOS 7
2017/10/17Tags: [ 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.dif 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
- Useful configurations
- Note: The set of valid template variables for
kernel.core_patternis usually available in the
.$pidto the core-file name. According to the documentation, this works only if the
kernel.core_patternpath does not contain a
fs.suid_dumpable=2has 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
DefaultLimitCORE=infinity(or possibly something more sensible than
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);
- This will invoke
Security implications of
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
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.