SELinuxDenyPtrace: Write, compile, run, but don't debug applications?

[Kevin Kofler]

Daniel J Walsh wrote:
> We did have a bug in Alpha where it was turned off.  Now that people are
> actually seeing it turned on in Fedora 17 Beta, they are reacting.

Uh no, I reacted back when you announced you would turn it on (which was 
also the first time I heard of the feature in the first place, since it 
wasn't discussed in the devel list, or at least not in the required level of 
detail to catch my attention, which your blog post did).

> If Fedora Board decides it should be turned off by default, I will of
> course abide by this decision.

Shouldn't this be a FESCo decision rather than a Board decision?

> I could turn it off for Fedora 17 final and on in Rawhide to find other
> problems with the feature.

Uh no, if the answer is you should turn it off, this means you should turn 
it off and keep it off.

> As I have stated in the blogs, this would be sad, since the goal of this
> feature is to protect the people who would never execute gdb -p, don't
> even know what gdb is.  IE The vast majority of computer users.

Again, there are many crash handlers for end users which run gdb -p 
internally. DrKonqi is just the most common one.

> So we will make the system insecure for the majority who will never turn
> on security features, since they expect the machine to be secure by
> default, for the developers who know fully how to turn off the feature, so
> they will not be inconvenienced.

Those crash handlers are not only for developers. They're also for normal 
end users to report crashes to upstream developers.

> Secondarily we do not know which software needs to be able to ptrace
> another process or what we get wrong with the feature without turning it
> on.  IE we did not know we broke DrKongi until we turned it on.

Wrong. I told you that it'll break DrKonqi right when you said you were 
going to turn it on. I didn't even have to test it to know, it was obvious. 
(Though tests did confirm it. In fact there's a bug filed (#808372), also 
because the workaround you recommended to us, setting the boolean in the 
%post script, is racy: In the bug's case, selinux-policy was updated between 
kde-runtime updates, so the %post script never runs. There might also be 
other error conditions, e.g., selinux-policy getting upgraded only after 
kde-runtime in the same transaction. I guess a trigger would be more 
reliable. But the best solution would be to just have the boolean be off by 
default in the first place!)

> We are trying to figure out a fix for DrKonji, but have no feedback from
> these people other then we suck so turn it off.  Lets work to figure out
> if we can do this feature with DrKonji.

Because DrKonqi fundamentally does gdb -p, i.e. exactly what you don't want.

The process GDB is going to be used on is its grandparent process (the 
parent of DrKonqi which is the parent of GDB). You'd have to allow at least 
tracing (grand)parent processes, but that'd probably allow attacking any 
process by going through parents and children in both directions. So I 
really don't see how DrKonqi and deny_ptrace can be made to work 
simultaenously.

You blame me for saying that the feature is fundamentally incompatible with 
DrKonqi, but that's just shooting the messenger. I cannot give you any other 
solution because I can't think of any, and in fact I don't think such a 
solution even mathematically exists at all (though a rigorous proof would 
require fully formalizing all the premises).

And I did answer all your questions about how DrKonqi works.

> One suggestion I have heard is to turn the feature off if someone install
> gdb like we do with DrKonji, which might be a better solution then
> disabling by default.

I disagree. Changing booleans in RPM scriptlets is a hack, and it doesn't 
work reliably as evidenced by bug #808372.

> Although abrt-desktop seems to require gdb...

… which also makes the idea of triggering this from gdb package scriptlets 
quite moot.

> Labeling an application and allowing a transition will not work as long as
> we have unconfined_t users.  For example it has been suggested that we
> label certain apps like gdb or DrKonji as ptrace_exec_t and then
> transition when these apps get executed.  Since an unconfined_t user can
> label any file as ptrace_exec_t and transition to the domains that allows
> ptrace.

That's a fundamental flaw of the SELinux security model.

> Changing the default user from unconfined_t to staff_t, would allow us to
> fix this problem, but I have a feeling the screaming about that would be
> overwhelming.

Indeed, that's even crazier than enabling deny_ptrace by default.

        Kevin Kofler