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]

Date:	Sat, 2 Sep 2006 21:03:23 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Andrew Morton <akpm@...l.org>, Andreas Hobein <ah2@...air.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>
Subject: Re: Trouble with ptrace self-attach rule since kernel > 2.6.14

On 09/01, Linus Torvalds wrote:
>
> 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.

I can't say whether it is safe to restore an old behaviour. This all is
tricky, and there were so many changes in that area since then.

At least we need to remove 'current->tgid != p->tgid' check in eligible_child().
Currently this is a dead code. But if we restore an old behaviour, this
allows to release ->group_leader too early and crash the kernel.

I personally do not see other problems right now, but this doesn't mean
they are not present...

On the other hand, if we are not going to go back, we can remove subtle
'tsk->parent->signal->flags & SIGNAL_GROUP_EXIT' check in exit_notify(),
and a similar one in may_ptrace_stop().

Oleg.


-- 
VGER BF report: H 0
-
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/