Re: Re: Asserts considered harmful (or GMP spills its sensitive information)

[Simon McVittie <smcv () debian org>]

On Tue, 01 Jan 2019 at 12:07:17 +0100, Niels Möller wrote:
> A security sensitive application can easily disable generation of core
> files, using setrlimit (on the linux kernel, prctl may also be useful).

If you want to avoid core dumps being recorded on Linux in the presence of
system configuration that writes them into a pipe to a command instead
of to a core file (systemd-coredump, corekeeper, abrt, apport etc.,
using a string starting with | in /proc/sys/kernel/core_pattern), then
you need to use prctl PR_SET_DUMPABLE. Setting RLIMIT_CORE to 0 prevents
the kernel from creating core dump files itself, but does not prevent
it from writing them to pipes.

It might be helpful to look at a recent version of dbus, which has a
reasonably portable implementation of "don't write core dumps", in a unit
test helper program that deliberately segfaults (so that the actual unit
test can assert that a segfaulting child process is handled correctly).
This was implemented to avoid core-collecting programs wasting time and
I/O bandwidth during unit test runs, rather than to avoid information
leaks, but the procedure is the same.

Some processes (including those that are setuid or setgid, I think?) are
automatically undumpable.

> And besides, most systems have zero ulimit -c as the system default
> these days

As noted above, this does not prevent writing the cores to pipes
(precisely to make crash-recording services like systemd-coredump more
useful).

> to get proper core dumps, including
> disabling the core dump collection "services" you mention

Crash-recording services should be able to provide a way to extract
the core from wherever they saved it, for example `coredumpctl -o... dump`
with systemd-coredump.

    smcv