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

Kees Cook kees at ubuntu.com
Thu Apr 12 16:19:17 UTC 2012


Hi,

On Thu, Apr 12, 2012 at 05:18:59PM +0200, Mark Wielaard wrote:
> On Thu, 2012-04-12 at 08:05 -0700, Kees Cook wrote:
> > Please just use Yama -- it's already in the mainline kernel[1]. You
> > don't need to create anything new. All the crash handlers and other
> > tools (Firefox, Chrome, DrKonqi/KDE, and Wine) are already aware of how
> > to declare ptrace relationships with prctl(PR_SET_PTRACER) from when I
> > wrote Yama and sent patches to various upstreams. Just allowing child
> > process relationships isn't sufficient, which is why PR_SET_PTRACER was
> > created so that things like Wine could declare the entire cluster of
> > wine-server-spawned processes as ptraceable, etc.
> > 
> > Why go a totally new route when all of these problems were already solved?
> 
> To be honest, and like we discussed on irc yesterday, it seems Yama has
> all the same problems like the current "solution". It denies ptrace
> attach to your own processes by default which is what breaks lots of
> things (we were discussing just jinfo/jstack/jmap yesterday, and I found
> that issue without even trying). None of the solutions that you claim
> Yama provides unbreaks these tools. IMHO just adding documentation and
> hoping users finds that and are allowed to unbreak their own setup isn't
> a real solution. It is fine to confine some applications so they cannot
> ptrace attach to arbitrary processes, but just globally disabling ptrace
> attach even for unconfined users is just rude IMHO, not to mention
> highly unsocial (as if our users wouldn't be hackers interested how
> stuff works).

Right, and that's where we disagree, which is fine. Ubuntu and Chrome OS
take the stance than improving the security of the bulk of their users
in this way outweighs the one-time inconvenience to some developers.

My point isn't whether or not to restrict ptrace, but rather, if you're
going to, please start with Yama and go from there. It's upstream, and
it already solves a number of problems associated with just globally
disabling ptrace, allowing for crash handlers and emulators to still do
their job.

-Kees

-- 
Kees Cook


More information about the devel mailing list