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

[Mark Wielaard]

Hi Dan,

On Mon, Apr 09, 2012 at 10:58:43AM -0400, Daniel J Walsh wrote:
> I thought I made this clear in my blogs and the feature page that I wanted
> this on deny_ptrace on by default.
> [...]
> 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.

My apologies I seem to react to this change so late. Now that I have seen
your other blog postings I see that was your intention. But I did see the
initial proposal and, like others, and FESCO, read it as making it an
option that could be turned on. But not by default. Because that creates
this situation that a normal users/developer needs to ask their admin to
fix their machine even though they can write, compile and run their own
programs, but suddenly aren't allowed to debug, profile or trace them.
If I had thought it would be turned on by default, I would have spoken
up sooner to try and help figure out something that wouldn't create such
a disruption.

> If Fedora Board decides it should be turned off by default, I will of course
> abide by this decision.  I could turn it off for Fedora 17 final and on in
> Rawhide to find other problems with the feature.

That seems a good idea. But if you want, please lets discuss what this
feature is really about and how we can give normal developers a good
out of the box experience, that doesn't involve them having to "unbreak"
their machine first before they can do their work.

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

I think it would set a bad precedent if we regard normal users as not being
able or interested in development. Fedora needs developers to push forward.
Also this suggests that if someone is a developer they should have lower
security for their system, even for programs that we know we normally want
to confine so they aren't able to do "bad stuff". It really shouldn't matter
that a user wants to run gdb, or some other introspection tool, on their
system to make their firefox plugins a bigger security risk.

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

But isn't this the wrong way around? Shouldn't you look for packages that
don't need the ability and make sure they run in a restricted context so
they cannot use features they don't want? What bothers me a bit is that
you are restricting the unconfined user by default. Wasn't the purpose
of the unconfined user to not be unecessarily be restricted by selinux?

> 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.  Although abrt-desktop seems to require gdb...

And then also disable the feature system wide when installing strace,
ltrace, perftools, or any other introspection tool that uses ptrace? But
doesn't that mean that depending on which packages you happen have
installed you get less security?

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

What are the applications we are worried about?
And why don't we just run those in a context that has ptrace disabled?
That is what normally happens with something like httpd isn't it?

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

Why would that not be a good solution?
(That is a serious question, I don't really know too much about selinux.)

Thanks,

Mark