From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: Trouble with ptrace self-attach rule since kernel > 2.6.14
Date: Fri, 01 Sep 2006 18:30:13 UTC
Message-ID: <fa.hAeZ7F9fnJ9fB1aXTml3t0vnb/c@ifi.uio.no>

On Fri, 1 Sep 2006, Andrew Morton wrote:
> On Fri, 1 Sep 2006 09:36:38 +0200
> Andreas Hobein <ah2@delair.de> wrote:
>
> > There is also a reply from Roland McGrath (see
> > http://lkml.org/lkml/2005/11/9/460) who mentioned that there may occur some
> > problems in "some real programs out there". May be I'm the first one who is
> > affected by this new behaviour.
>
> When you have names, please cc them..

Andreas isn't the first, but in the almost-a-year that the patch has been
part of the kernel, he's the second.

And for the first one I found a reasonable way to avoid the problem: the
debugging thread can do a "vfork()" (or, if vfork() does something bad in
libc, do the direct "clone(CLONE_VFORK|CLONE_MM)" thing) to have a new
thread that is in a _different_ thread group, but is able to ptrace and
also is "synchronized" with the VM, simply because it shares it with all
the other threads it might want to debug.

That "new" (last November) check isn't likely going away. It solved _so_
many problems (both security and stability), and considering that

 (a) in a year, only two people have ever even _noticed_
 (b) there's a work-around as per above that isn't horribly invasive

I have to say that in order to actually go back to the old behaviour, we'd
have to have somebody who cares _deeply_, go back and check every single
special case, deadlock, and race.

Not allowing ptracing to send signals and be part of the same thread group
really got rid of a _lot_ of complexity (and bugs - I don't mind
complexity per se, but complexity that was known broken and nobody could
really see a good solution for, and had both security and stability
implications is a bad bad thing).

But if somebody does feel that "deep caring feeling", I'll try to help
them. Maybe Roland and Oleg Nesterov might lend a hand too (Oleg in
particular by now probably knows all the races in that area, including
pthread parents sending signals to its own thread and de-parenting etc).

Hint, hint, Andreas. But I think it's a rats' nest, and you'd be better
off trying the CLONE_MM|CLONE_VFORK approach.

Oleg (now added to the Cc) in particular may answer authoritatively
whether maybe his fixes since last year have fixed some of the problems,
or whether they do indeed depend even more on the fact that the ptrace
"fake parent" cannot be in the same thread group.

(Even if we could make it work, I personally much prefer the fact that a
ptrace parent is forced to behave more like a "real parent" - who also
cannot be in the same thread group).

		Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: Trouble with ptrace self-attach rule since kernel > 2.6.14
Date: Mon, 04 Sep 2006 22:03:03 UTC
Message-ID: <fa.be6uf66IGcVI9L/WXa7JmX42bm0@ifi.uio.no>

On Mon, 4 Sep 2006, Andreas Hobein wrote:
>
> I've tested tracing child threads from the parent thread as well as tracing
> siblings and parent threads from a child. All tests where successful when
> reverting the above mentioned changes.

The problems tend to happen when the thread leader exits while one of the
sub-threads is being traced, and the tracer thread ends up being
re-parented to be the child of the traced thread (or something like that -
I forget the exact details).

There was also some problem with the tracer doing an exit() without
detaching, or something.

We may have fixed most of the problems since - Oleg has certainly been
cleaning up some of this, and it's possible that the problems we had are
ok now.

Even back when it was broken, _normal_ use never showed the problem (ie no
well-behaved ptrace use would cause anything bad to happen). But the
breakage was a local DoS attack, where you could either force an oops or a
unkillable process, I forget which.

There was an exploit for at least one of the exploits, so maybe somebody
could test that exploit together with the one-line revert.

That said, it sounds like both of the people who ever noticed this are
reasonably happy with their work-arounds, so I'm hoping we can simply
decide not to care, and just keep doing the simpler "you can't ptrace your
own thread group" thing. That rule simply avoids a lot of special cases.

			Linus