Bug 808372

I guess the setroubleshoot tells you what to do and I guess you read Dan's blog.

(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

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.

(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

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.

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.

How does DrKonqi handle the YAMA ptrace restrictions which I believe are now default in Ubuntu.  Do they use the ptrace registration interface?

(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?

> 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.

(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)

Yes confined applications and non root users should be blocked from reading corefiles collected by abrt.  

Does DrKonji run as root?

Of course not, that would be a completely pointless security risk!

(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.)

(And it's "DrKonqi" with a 'Q', it's named after Konqi the dragon, whose name is a diminutive of "Konqueror".)

How exactly do apps exec DrKonqi?  Does this work for all apps run in the user domain or only kde apps?

> 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.)

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.

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

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.