• 1
Actually, I now realize why ABRT doesn't need this access: it doesn't attach to a running process, but to a core dump.

DrKonqi is KDE's crash handler. It is in Fedora, because it is part of kdelibs (libkdeui) and kde-runtime. All the KDE GUI apps use it. Unlike ABRT, it reports the bugs to KDE upstream's Bugzilla, which makes a lot more sense because they are the ones who have to fix the bugs anyway.

But DrKonqi works very differently from how ABRT works. This is how DrKonqi operates:
* KApplication in libkdeui installs a crash handler called KCrash. That crash handler intercepts SIGSEGV, SIGABRT etc., fires up an external drkonqi executable, then blocks the process.
* The drkonqi executable (in kde-runtime) brings up the DrKonqi UI, which displays some information passed on the command line and offers to report the bug and/or to restart the crashed application.
* There is a tab in the DrKonqi UI (and also a required step if you are going to report the bug to the developers) which produces a backtrace. To do so, DrKonqi attaches GDB to the crashed process (which the crash handler blocked, but did not terminate, so this is a real live process, not a core dump) and asks it for a backtrace.

So, in short, I believe everything other than disabling deny_ptrace by default WILL break DrKonqi! You cannot even use "a domain that unconfined_t can not transition to, but systemd (init_t) can" because DrKonqi is not started by systemd, but by the crashed application. (Well, to make things even more complicated, by default, DrKonqi is actually started by kdeinit4, which is started within the user startkde session, but any application can ask kdeinit4 to start anything, so if kdeinit4 can transition to something, the user effectively can, too. This is a hack KDE uses to have to load the KDE libraries into memory only once and always fork the process with those libraries already loaded.)

The easiest way to test DrKonqi is to install kwrite and to run:
kwrite &
killall -SIGABRT kwrite
This will be intercepted by DrKonqi (not ABRT, because KCrash intercepts the crash while the process is still live and triggers DrKonqi, so ABRT doesn't get a chance to see the crash, because ABRT triggers only when the process terminates and core dumps).

As far as I know, there are also other upstream projects using bug handlers which work like DrKonqi. ABRT is the only bug handler I know which uses core dumps. You are going to break all those bug handlers.

Re: DrKonqi, ABRT etc.

THen I guess I would tell the DrKongi tool to disable the boolean. I still feel this is enough of a feature to allow most of gnome users and therefore most of Fedora users the ability to stop apps from examining other apps memory.

So first of all, it's called "DrKonqi" with a 'q' (lowercase 'Q'), it's named after "Konqi", the mascot of KDE and Konqueror.

DrKonqi is used by all apps built on the KDE Platform (kdelibs and related libraries), independently of the desktop environment you run it under. There are many users of GNOME and other non-KDE desktops using e.g. K3b, Kile etc. By breaking DrKonqi, you will break those applications' automated bug reporting and thus actively sabotage upstream's efforts to fix crash bugs. It is just not an acceptable default.

And how would we disable the boolean? I guess we could run setsebool in the KDE spin kickstart, but that would not help for all the users of kdelibs-based applications under other desktops, nor for KDE Plasma Workspace users installing from the DVD.

And finally, while DrKonqi is the one I'm familiar with, I'm fairly sure there are other crash reporting tools working the same way.

Re: DrKonqi, ABRT etc.

Whatever rpm installs the DrKonqi functionality should check in its post install if the deny_ptrace is turned on and then disable it iff it is the initial install.

setsebool -P deny_ptrace 1

If any other package needs this functionality it could to the same, then each of us are happy.

  • 1

Log in