From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753055AbbJTRkP (ORCPT <rfc822;w@1wt.eu>);
	Tue, 20 Oct 2015 13:40:15 -0400
Received: from mx1.redhat.com ([209.132.183.28]:59567 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753021AbbJTRkL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 20 Oct 2015 13:40:11 -0400
Date: Tue, 20 Oct 2015 19:36:36 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
        Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>,
        Denys Vlasenko <dvlasenk@redhat.com>,
        Eric Dumazet <edumazet@google.com>,
        Jan Kratochvil <jan.kratochvil@redhat.com>,
        Julien Tinnes <jln@google.com>, Kees Cook <keescook@google.com>,
        Kostya Serebryany <kcc@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
        Pedro Alves <palves@redhat.com>, Robert Swiecki <swiecki@google.com>,
        Roland McGrath <roland@hack.frob.com>, syzkaller@googlegroups.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] wait/ptrace: always assume __WALL if the child is
	traced
Message-ID: <20151020173636.GA29562@redhat.com>
References: <20151020171740.GA29290@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151020171740.GA29290@redhat.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Forgot to say...

Another question is why PTRACE_TRACEME succeeds in this case. I guess
it is to late to change (break) the rules, but I never understood the
security checks. The comment above cap_ptrace_traceme() says:

	Determine whether another process may trace the current

and "another process" is parent. To me this looks strange, imo we should
determine whether the current may abuse its parent. So perhaps we could
change ptrace_traceme() to fail if

	current->parent_exec_id != parent->self_exec_id

?

But this too can break something. Although I can't imagine why the
child reaper or a PR_SET_CHILD_SUBREAPER process may want to trace
the reparented tasks.

On 10/20, Oleg Nesterov wrote:
>
> Damn. I simply do not know what should/can we do. From the change
> log:
>
> 	And I can only hope that this won't break something.
>
> yet this patch cc's -stable.
>
>
> Please see the changelog, but in short: this is not a kernel bug
> but unlikely we can fix all distributions, so I think we have to
> change the kernel.
>
> HOWEVER. With this change __WCLONE and __WALL have no effect for
> debugger, do_wait() works as if __WALL is set if the child (natural
> or not) is traced.
>
>
> Jan, Pedro, could you please confirm this won't break gdb? I tried
> to look into gdb-7.1, and at first glance gdb uses __WCLONE only
> because __WALL doesn't work on older kernels, iow it seems to me
> that gdb actually wants __WALL so this change should be fine.
>
>
> Any other ideas?
>
> Oleg.