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

[Mark Wielaard]

On Thu, Apr 12, 2012 at 04:01:58PM -0400, Daniel J Walsh wrote:
> On 04/12/2012 02:39 PM, Mark Wielaard wrote:
> > On Mon, Apr 09, 2012 at 09:38:40AM -0400, Eric Paris wrote:
> >> (Think about it a moment.  gdb -p is the same as firefox trying to ptrace
> >> gnome-keyring)
> > 
> > I thought a bit about it. And now I am even more confused :)
> > 
> > It seems you are already not allowed to ptrace gnome-keyring-daemon (or
> > ssh-agent because that is setuid). So is there a better example than
> > gnome-keyring or ssh-agent to show why we would like to clobber ptrace
> > globally?
> 
> Ok kinit, ssh, pwsafe ...

But these are different aren't they? Because they aren't long running
daemons holding security/authentication credentials for the user. To
exploit these you would not have to ptrace attach to them, but will have
to actively start a run of them and trick the user into typing in their
passwords. Or do you mean they could ptrace some other process when they
are compromised?

> evince ptracing firefox

And this seems yet another different security threat, where you have a
desktop app that might execute untrusted data to get exploited. Doesn't
it make sense to confine these applications like we confine say httpd so
they cannot meddle with other programs directly?

Does firefox hold security credentials itself? If so, would it make
sense to deal with this threat by moving those to a small secured
deamon that is protected the same way ssh-agent/gnome-keyring are?

I am just looking for specific security threats and see if they can be
handled in a nicer way than clobbering ptrace globally. It seems we
already have something for the security deamons running on behave of
the user (ssh-agent/gnome-keyring-daemon), so hopefully we can find
similar protections for other cases before we start globally stopping
anybody from ptracing unless they get elivated privileges first to
unbreak their machines.

Thanks,

Mark