Bug 808372 - SELinux is preventing DrKonqi from getting backtraces
Summary: SELinux is preventing DrKonqi from getting backtraces
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-30 09:42 UTC by Karel Volný
Modified: 2013-07-06 09:52 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-04 10:52:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Karel Volný 2012-03-30 09:42:00 UTC
Description of problem:
My wife does not debug programs, why is she NOT allowed to let DrKonqi to help the developers to debug them?

Version-Release number of selected component (if applicable):
Fedora 17 Alpha

How reproducible:
always

Steps to Reproduce:
1. crash some KDE application, wait for DrKonqi to appear
2. try to load backtrace in DrKonqi
  
Actual results:
no backtrace, can't report the bug

Expected results:
full backtrace, bug reporting via DrKonqi works as expected

Additional info:

Comment 1 Miroslav Grepl 2012-03-30 09:50:35 UTC
I guess the setroubleshoot tells you what to do and I guess you read Dan's blog.

Comment 2 Karel Volný 2012-03-30 10:34:46 UTC
(In reply to comment #1)
> I guess the setroubleshoot tells you what to do

yes, it tells me to give root to my wife (well, to my mother-in-law to be precise)

$ setsebool -P deny_ptrace 0
Cannot set persistent booleans, please try as root.
Could not change policy booleans

> and I guess you read Dan's blog.

yes, where do you think that I got the paraphrase from? :-)

and I've also read the Feature page at https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace

and it says:

"We should not be seeing AVC's from common running applications when this boolean is turned on, if we do then a bugzilla should be opened against SELinux."

so I've opened a bugzilla, as I've saw AVC from common running application

Comment 3 Daniel Walsh 2012-03-30 17:50:54 UTC
Not sure how DrKongi works but we are working to allow apps to ptrace their children while preventing apps from ptracing random processes on the system.  Hopefully the kernel will have this before we ship.

Setting this boolean will allow you to run the way you always did before, and allow the rest of the world which does not use DrKongi to work with added security.

Comment 4 Karel Volný 2012-04-02 13:38:21 UTC
(In reply to comment #3)
> Not sure how DrKongi works but we are working to allow apps to ptrace their
> children while preventing apps from ptracing random processes on the system. 

it is not "random process on the system" but rather "an application which uses KDE crash handler", AFAIK

CCing Kevin to explain, pls

> Setting this boolean will allow you to run the way you always did before,

well, no

before, I NEVER had to set something like this, Fedora has worked out of the box (except the obvious bugs which were fixed, as usual)

let me remind you once again the desired user experience from the feature description:

"We should not be seeing AVC's from common running applications when this
boolean is turned on ..."

now I've seen AVC from common application, which is in violation with the feature requirements, so please fix

> and allow the rest of the world which does not use DrKongi

it is not "me versus the rest of the world", please refrain from such fallacies

> to work with added security.

you actually mean to work with LESS security, as turning selinux off (or, alternatively, giving root to any random user) is what you are teaching people

Comment 5 Kevin Kofler 2012-04-02 14:18:50 UTC
kde-runtime is supposed to set the boolean from its %post script (which is what Dan Walsh recommended to do), does that not work?

I agree that a broken DrKonqi is a no-go and will propose this as a release blocker if confirmed. I still think deny_ptrace should be off by default.

Comment 6 Rex Dieter 2012-04-02 15:01:21 UTC
I saw a similar oddness wrt this awhile back, my deny_ptrace bool got turned back on somehow, and a subsequent kde-runtime pkg (with it's scriptlet) turned it off again.

Comment 7 Eric Paris 2012-04-02 19:43:36 UTC
How does DrKonqi handle the YAMA ptrace restrictions which I believe are now default in Ubuntu.  Do they use the ptrace registration interface?

Comment 8 Karel Volný 2012-04-03 10:28:33 UTC
(In reply to comment #5)
> kde-runtime is supposed to set the boolean from its %post script (which is what
> Dan Walsh recommended to do), does that not work?

obviously that hasn't worked for me as I've hit the issue ... see also comment #6, maybe it has worked but it got overriden by something else

however, what I see as a problem is that this is just a workaround - it is the "turn off selinux" case ... just because kde-runtime gets installed, users (also GNOME users which got that just as some dependency) will get the feature switched off

> I still think deny_ptrace should be off by default.

let me disagree - I think that the idea behind this is great, it just needs to be polished so that it doesn't get into the way for valid use cases without having to switch it off completely (see above)


*****

hm, thinking about it a bit ...

DrKonqi can't get the backtrace because it reads memory

reading the memory is disabled because some rogue application can get some sensitive data


but abrt can get the backtrace because it reads core file

reading core files is not disabled

what if the rogue application sends SIGABRT to the victim and then reads the core file which contains what was in the memory?

is that possible or are we already protected from this scenario?
- I've noticed that sending signals is somehow limited, but trying this from commandline, nothing has stopped "kill -6 $pid", what would stop the rogue application running this command instead of me?

Comment 9 Kevin Kofler 2012-04-03 11:03:05 UTC
> let me disagree - I think that the idea behind this is great, it just needs to
> be polished so that it doesn't get into the way for valid use cases without
> having to switch it off completely (see above)

The "idea behind this" is fundamentally incompatible with DrKonqi.

Comment 10 Karel Volný 2012-04-03 11:26:44 UTC
(In reply to comment #9)
> > let me disagree - I think that the idea behind this is great, it just needs to
> > be polished so that it doesn't get into the way for valid use cases without
> > having to switch it off completely (see above)
> 
> The "idea behind this" is fundamentally incompatible with DrKonqi.

well, then I got it wrong, as usual :-)

in any case, I'd like to see reporting crashes as easy as possible, so that they can be fixed - users want to *use* the computers, not have them as expensive paperweights as they are denied to do basic things (and I, as a (self)admin, really do not want to spend rest of my days reading howtos and googling how to enable those things that do not work out-of-the box without apparent reason)

Comment 11 Daniel Walsh 2012-04-05 20:44:50 UTC
Yes confined applications and non root users should be blocked from reading corefiles collected by abrt.  

Does DrKonji run as root?

Comment 12 Kevin Kofler 2012-04-05 21:13:22 UTC
Of course not, that would be a completely pointless security risk!

Comment 13 Kevin Kofler 2012-04-05 21:14:13 UTC
(unless it's spawned by an app running as root, of course. Remember that DrKonqi is spawned by the crashed app itself, not by the kernel like ABRT.)

Comment 14 Kevin Kofler 2012-04-05 21:18:02 UTC
(And it's "DrKonqi" with a 'Q', it's named after Konqi the dragon, whose name is a diminutive of "Konqueror".)

Comment 15 Daniel Walsh 2012-04-09 19:55:26 UTC
How exactly do apps exec DrKonqi?  Does this work for all apps run in the user domain or only kde apps?

Comment 16 Kevin Kofler 2012-04-09 21:39:35 UTC
> How exactly do apps exec DrKonqi?

KApplication in kdeui installs a crash handler called KCrash which intercepts the signals and execs DrKonqi.

> Does this work for all apps run in the user domain or only kde apps?

It triggers on all apps using libkdeui and KApplication, i.e. all graphical applications using the KDE Platform. (And there are plans to make it work also for command-line libkdecore applications, though there aren't many of those.)

Comment 17 Fedora End Of Life 2013-07-04 00:50:09 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 Karel Volný 2013-07-04 10:52:41 UTC
on a clean install of F18, and even after update to F19, DrKonqui seems to work out of the box, so probably there's no point in keeping this open

Comment 19 Kevin Kofler 2013-07-06 09:52:54 UTC
See also bug #802072 for the underlying issue (which is still not fixed): SELinux deny_ptrace needs to support the same registration API as YAMA.


Note You need to log in before you can comment on or make changes to this bug.