linux-kernel - Re: [PATCH] ptrace: allow restriction of ptrace scope

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100617004624.GR24749@outflux.net>
Date:	Wed, 16 Jun 2010 17:46:24 -0700
From:	Kees Cook <kees.cook@...onical.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Dave Young <hidave.darkstar@...il.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Oleg Nesterov <oleg@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Howells <dhowells@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH] ptrace: allow restriction of ptrace scope

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/