linux-kernel - Re: Trouble with ptrace self-attach rule since kernel

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: <Pine.LNX.4.64.0609011117440.27779@g5.osdl.org>
Date:	Fri, 1 Sep 2006 11:28:54 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Andrew Morton <akpm@...l.org>
cc:	Andreas Hobein <ah2@...air.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...sign.ru>
Subject: Re: Trouble with ptrace self-attach rule since kernel > 2.6.14

On Fri, 1 Sep 2006, Andrew Morton wrote:
> On Fri, 1 Sep 2006 09:36:38 +0200
> Andreas Hobein <ah2@...air.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
-
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/