linux-kernel - Re: [PATCH 0/2] wait/ptrace: always assume _

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: <20151020173636.GA29562@redhat.com>
Date:	Tue, 20 Oct 2015 19:36:36 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitry Vyukov <dvyukov@...gle.com>
Cc:	Alexander Potapenko <glider@...gle.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	Julien Tinnes <jln@...gle.com>,
	Kees Cook <keescook@...gle.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	Pedro Alves <palves@...hat.com>,
	Robert Swiecki <swiecki@...gle.com>,
	Roland McGrath <roland@...k.frob.com>,
	syzkaller@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] wait/ptrace: always assume __WALL if the child is
	traced

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.

--
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/