https://bugzilla.suse.com/show_bug.cgi?id=1203493 https://bugzilla.suse.com/show_bug.cgi?id=1203493#c8 Matthias Gerstner <matthias.gerstner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #8 from Matthias Gerstner <matthias.gerstner@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.