Re: [PATCH] ptrace: allow restriction of ptrace scope

[Kees Cook]

On Wed, Jun 16, 2010 at 05:11:14PM -0700, Roland McGrath wrote:
> > Though, honestly, just trying to get rid of PTRACE seems like the better
> > place to spend time.
> 
> Crushing irony of telling *me* this duly noted.  ;-)
> I am not really sure what deeply different set of security constraints
> you envision on any other kind of new debugger interface that would be
> any different for the concerns you've expressed, though.

I haven't though too much about replacements, but it seems like having
a way for processes to declare who/what can debug them is the way to go.
I realize this is very close to MAC policy, but having this be more
general-purpose seems valuable.

Like, a different version of PTRACE_TRACEME, something like PTRACE_BY_YOU.
Imagined example with total lack of error checking and invalid syntax...

void segfault_handler(void) {
	pid = horrible_dbus_insanity("spawn a debugger");
	prctl(PR_SET_DEBUGGER, pid);
}

PTRACE_TRACEME would be effectively the same as:

void segfault_handler(void) {
	if (pid = fork()) {
		execl(debugger,getppid());
		exit(1);
	} else {
		prctl(PR_SET_DEBUGGER, pid);
	}
}

> > > I suspect you really want to test same_thread_group(walker, current).
> > > You don't actually mean to rule out a debugger that forks children with
> > > one thread and calls ptrace with another, do you?
> > 
> > Won't they ultimately have the same parent, though?
> 
> Sure, those debugger threads will have the same parent, such as the shell
> that spawned the debugger.  But your "security" check is that the caller of
> ptrace is a direct ancestor of the tracee.  The ancestry of that ptrace
> caller is immaterial.

Ah right, sorry, I was being too literal (thought in your example the
parent didn't fork a debugger and called ptrace on its children).

Right, this would probably solve the Chrome case, but not KDE, which seems
to fork the crash handler from very far away.  I haven't looked too closely
there yet.

-Kees

-- 
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/