From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751169AbdJCTGA convert rfc822-to-8bit (ORCPT ); Tue, 3 Oct 2017 15:06:00 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:46273 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750787AbdJCTF7 (ORCPT ); Tue, 3 Oct 2017 15:05:59 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: =?utf-8?Q?J=C3=BCrg?= Billeter Cc: Andrew Morton , Oleg Nesterov , Linus Torvalds , Michael Kerrisk , Filipe Brandenburger , David Wilcox , hansecke@gmail.com, linux-kernel@vger.kernel.org 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> <1507052834.19102.53.camel@bitron.ch> Date: Tue, 03 Oct 2017 14:05:40 -0500 In-Reply-To: <1507052834.19102.53.camel@bitron.ch> (=?utf-8?Q?=22J=C3=BCrg?= Billeter"'s message of "Tue, 03 Oct 2017 19:47:14 +0200") Message-ID: <87shf09hmj.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1dzSVs-0003yK-D5;;;mid=<87shf09hmj.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.200.44;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX194gfuZmL8m1GprogfgsT3GfXccFyasoqg= X-SA-Exim-Connect-IP: 67.3.200.44 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4992] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: =?ISO-8859-1?Q?*;J=c3=bcrg Billeter ?= X-Spam-Relay-Country: X-Spam-Timing: total 5357 ms - load_scoreonly_sql: 0.21 (0.0%), signal_user_changed: 9 (0.2%), b_tie_ro: 4.5 (0.1%), parse: 2.9 (0.1%), extract_message_metadata: 32 (0.6%), get_uri_detail_list: 2.2 (0.0%), tests_pri_-1000: 12 (0.2%), tests_pri_-950: 3.1 (0.1%), tests_pri_-900: 2.6 (0.0%), tests_pri_-400: 34 (0.6%), check_bayes: 31 (0.6%), b_tokenize: 12 (0.2%), b_tok_get_all: 7 (0.1%), b_comp_prob: 4.8 (0.1%), b_tok_touch_all: 3.0 (0.1%), b_finish: 1.25 (0.0%), tests_pri_0: 753 (14.1%), check_dkim_signature: 1.24 (0.0%), check_dkim_adsp: 6 (0.1%), tests_pri_500: 4499 (84.0%), poll_dns_idle: 4468 (83.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jürg Billeter writes: > On Tue, 2017-10-03 at 12:40 -0500, Eric W. Biederman wrote: >> Jürg Billeter 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? We discussed this early on, and the decision was that no_new_privs would be kept simple and the user namespace would be what enabled additional functionality. Given how much of a challenge dealing with the additional attack surface of enabling additional functionality in the kernel I think that was the right call. That has been the difference between no_new_privs being done and user namespaces interesting since they have been merged. Eric