Comment # 8 on bug 1203493 from Matthias Gerstner

The privileged component of this has about 1.000 lines of C++ code and looks
good so far. The service is invoked alongside systemd-coredump and scans the
journal for a core dump message from systemd-coredump. It extracts the
necessary metadata from the journal and forwards it (if possible) to the
unprivileged user the dump is for via a UNIX domain socket in
/run/user/<UID>/drkonqi-coredump-launcher. The metadata is forwarded as JSON.

The privileged service only scans the journal as input, there should not be
any attack surface there. The service scans explicitly for a journal entry
from the concrete systemd-coredump instance. Forging these type of journal
entry from non-privileged contexts hopefully is not possible.

On the unprivileged side the UNIX domain socket is created in /run with a mode
of 0600, thus only privileged users will be able to forward data there. I
don't really need to look into the rest of the unprivileged code since there
should not be any untrusted input into it.

One part that surprises me a bit is the handling of setuid processes. The
kernel implements the fs.suid_dumpable sysctl that should control what happens
with core dumps from setuid processes. By default it is set to 2 these days
meaning that core dumps should be generated but not be accessible to non-root
users. I would have guessed that systemd-coredump respects this setting, too.
However it does not differentiate, and a setuid-root process will be dumped
and the dump will be readable by the real user ID of the process.

drkonqi also takes no precations in this regard. Although it could at least
interpret the OWNER_UID metadata key instead of the UID key (although it
currently seems unused for this scenario).

Maybe we should ask systemd-coredump upstream what their take is on this,
maybe they're not aware of it. setuid processes can contain additional
sensitive data that normally are not accessible to the user invoking them.
Often the data can also be helpful in exploiting other security issues in
setuid-root binaries.