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