public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees.cook@canonical.com>
To: Roland McGrath <roland@redhat.com>
Cc: linux-kernel@vger.kernel.org, Randy Dunlap <rdunlap@xenotime.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Dave Young <hidave.darkstar@gmail.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Oleg Nesterov <oleg@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Howells <dhowells@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH] ptrace: allow restriction of ptrace scope
Date: Wed, 16 Jun 2010 17:46:24 -0700	[thread overview]
Message-ID: <20100617004624.GR24749@outflux.net> (raw)
In-Reply-To: <20100617001114.A90F5403D2@magilla.sf.frob.com>

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

  reply	other threads:[~2010-06-17  0:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16 22:18 [PATCH] ptrace: allow restriction of ptrace scope Kees Cook
2010-06-16 23:01 ` Alan Cox
2010-06-16 23:22   ` Kees Cook
2010-06-17 13:45     ` James Morris
2010-06-17 17:04       ` Kees Cook
2010-06-17 20:53         ` Alan Cox
2010-06-17 21:06           ` Randy Dunlap
2010-06-17 21:16             ` Kees Cook
2010-06-17 22:18               ` Alan Cox
2010-06-17 22:25                 ` Kees Cook
2010-06-17 22:34                   ` Alan Cox
2010-06-17 21:18             ` Alan Cox
2010-06-17 21:51               ` Kees Cook
2010-06-17 22:30                 ` Alan Cox
2010-06-17 23:03                   ` James Morris
2010-06-18  3:10                   ` Casey Schaufler
2010-06-18 10:54                     ` Theodore Tso
2010-06-18 13:50                       ` Eric W. Biederman
2010-06-18 14:29                         ` Serge E. Hallyn
2010-06-19  2:23                         ` Casey Schaufler
2010-06-19  2:49                           ` Eric W. Biederman
2010-06-21  0:52                       ` James Morris
2010-06-21  2:16                         ` Valdis.Kletnieks
2010-06-18 17:58                   ` Kees Cook
2010-06-19  2:15                 ` Tetsuo Handa
2010-06-19  3:19                 ` Frank Ch. Eigler
2010-06-16 23:10 ` Roland McGrath
2010-06-16 23:39   ` Kees Cook
2010-06-17  0:11     ` Roland McGrath
2010-06-17  0:46       ` Kees Cook [this message]
2010-06-18 12:36       ` Serge E. Hallyn
2010-06-17 12:29 ` Eric W. Biederman
2010-06-17 16:59   ` Kees Cook
2010-06-17 20:45     ` Eric W. Biederman
2010-06-17 21:14       ` Kees Cook
2010-06-17 22:50       ` Serge E. Hallyn
2010-06-17 23:11         ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100617004624.GR24749@outflux.net \
    --to=kees.cook@canonical.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hidave.darkstar@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jkosina@suse.cz \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=rdunlap@xenotime.net \
    --cc=roland@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox