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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
