From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755225AbdJIQck convert rfc822-to-8bit (ORCPT ); Mon, 9 Oct 2017 12:32:40 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:51962 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754478AbdJIQci (ORCPT ); Mon, 9 Oct 2017 12:32:38 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: =?utf-8?Q?J=C3=BCrg?= Billeter Cc: Oleg Nesterov , Andy Lutomirski , Andrew Morton , 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> <20171005162733.GA20068@redhat.com> <1507484845.62760.23.camel@bitron.ch> Date: Mon, 09 Oct 2017 11:32:13 -0500 In-Reply-To: <1507484845.62760.23.camel@bitron.ch> (=?utf-8?Q?=22J=C3=BCrg?= Billeter"'s message of "Sun, 08 Oct 2017 19:47:25 +0200") Message-ID: <878tgk5lki.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=1e1ayk-0001fK-Oi;;;mid=<878tgk5lki.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.200.44;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+lvia9iwyp4XDE7zwIa3dWaFGO4+cGfok= 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 * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 TR_Symld_Words too many words that have symbols inside * 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.4812] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 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 5307 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 4.4 (0.1%), b_tie_ro: 3.7 (0.1%), parse: 1.22 (0.0%), extract_message_metadata: 16 (0.3%), get_uri_detail_list: 1.60 (0.0%), tests_pri_-1000: 6 (0.1%), tests_pri_-950: 1.57 (0.0%), tests_pri_-900: 1.32 (0.0%), tests_pri_-400: 26 (0.5%), check_bayes: 25 (0.5%), b_tokenize: 10 (0.2%), b_tok_get_all: 7 (0.1%), b_comp_prob: 3.2 (0.1%), b_tok_touch_all: 2.5 (0.0%), b_finish: 0.61 (0.0%), tests_pri_0: 561 (10.6%), check_dkim_signature: 0.72 (0.0%), check_dkim_adsp: 4.6 (0.1%), tests_pri_500: 4686 (88.3%), poll_dns_idle: 4679 (88.2%), 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 in01.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 Thu, 2017-10-05 at 18:27 +0200, Oleg Nesterov wrote: >> On 10/03, Jürg Billeter wrote: >> > >> > My use case is to provide a way for a process to spawn a child and >> > ensure that no descendants survive when that child dies. Avoiding >> > runaway processes is desirable in many situations. My motivation is >> > very lightweight (nested) sandboxing (every process is potentially >> > sandboxed). >> > >> > I.e., pid namespaces would be a pretty good fit (assuming they are >> > sufficiently lightweight) but CLONE_NEWPID >> >> sorry if this was already discussed, I didn't read this thread yet... >> >> if CLONE_NEWPID is not suitable for any reason. We already have >> PR_SET_CHILD_SUBREAPER. Perhaps we can simply add another >> PR_SET_KILL_ALL_DESCEDANTS_ON_EXIT? we can use walk_process_tree() >> to send SIGKILL. > > Yes, this is an option. However, after the discussion in this thread I > believe it would be better to drop the CAP_SYS_ADMIN requirement for > CLONE_NEWPID (when no_new_privs is set) as this would avoid adding > another API and code path for a similar effect. I'm interested in > possible security concerns about such a change. Adding Andy Lutomirski > to cc. Absolutely not. no_new_privs does not need the headache of being increasing the kernel attack surface. User namespaces are cheap, use one. Let the people using no_new_privs sleep easy. We don't need to transform no_new_privs into a user namespace. Eric