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 S1751450AbdJCRrx convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Tue, 3 Oct 2017 13:47:53 -0400
Received: from nov-007-i542.relay.mailchannels.net ([46.232.183.96]:60344 "EHLO
        nov-007-i542.relay.mailchannels.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1750767AbdJCRrw (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 3 Oct 2017 13:47:52 -0400
X-Sender-Id: novatrend|x-authuser|juerg@bitron.ch
X-Sender-Id: novatrend|x-authuser|juerg@bitron.ch
X-MC-Relay: Neutral
X-MailChannels-SenderId: novatrend|x-authuser|juerg@bitron.ch
X-MailChannels-Auth-Id: novatrend
X-Irritate-Trail: 5be7abe330c79d61_1507052866942_239785715
X-MC-Loop-Signature: 1507052866942:1019459272
X-MC-Ingress-Time: 1507052866941
Message-ID: <1507052834.19102.53.camel@bitron.ch>
Subject: Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC
From: =?ISO-8859-1?Q?J=FCrg?= Billeter <j@bitron.ch>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Filipe Brandenburger <filbranden@google.com>,
        David Wilcox <davidvsthegiant@gmail.com>, hansecke@gmail.com,
        linux-kernel@vger.kernel.org
Date: Tue, 03 Oct 2017 19:47:14 +0200
In-Reply-To: <8760bwb04k.fsf@xmission.com>
References: <20170909094008.49983-1-j@bitron.ch>
         <20170929123058.48924-1-j@bitron.ch>
         <20171002162041.a7cefe8af71327b8becd2347@linux-foundation.org>
         <87o9pogbf7.fsf@xmission.com> <1507013157.2304.48.camel@bitron.ch>
         <878tgse1c5.fsf@xmission.com> <1507050019.19102.51.camel@bitron.ch>
         <8760bwb04k.fsf@xmission.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.1 
Mime-Version: 1.0
X-AuthUser: juerg@bitron.ch
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 2017-10-03 at 12:40 -0500, Eric W. Biederman wrote:
> Jürg Billeter <j@bitron.ch> writes:
> > What's actually the reason that CLONE_NEWPID requires CAP_SYS_ADMIN? 
> > Does CLONE_NEWPID pose any risks that don't exist for
> > CLONE_NEWUSER|CLONE_NEWPID?  Assuming we can't simply drop the
> > CAP_SYS_ADMIN requirement, do you see a better solution for this use
> > case?
> 
> CLONE_NEWPID without a permission check would allow runing a setuid root
> application in a pid namespace.  Off the top of my head I can't think of
> a really good exploit.  But when you mess up pid files, and hide
> information from a privileged application I can completely imagine
> forcing that application to misbehave in ways the attacker can control.
> Leading to bad things.

Could we allow unprivileged CLONE_NEWPID if the no_new_privs bit is
set?

Jürg