Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753961AbdLUVp2 convert rfc822-to-8bit (ORCPT ); Thu, 21 Dec 2017 16:45:28 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:40276 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751705AbdLUVpW (ORCPT ); Thu, 21 Dec 2017 16:45:22 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Maciej =?utf-8?Q?=C5=BBenczykowski?= Cc: Maciej =?utf-8?Q?=C5=BBenczykowski?= , linux-security-module@vger.kernel.org, Linux Kernel Mailing List , Mahesh Bandewar , Willem de Bruijn , Linux Containers References: <20171221210605.181720-1-zenczykowski@gmail.com> Date: Thu, 21 Dec 2017 15:44:53 -0600 In-Reply-To: <20171221210605.181720-1-zenczykowski@gmail.com> ("Maciej \=\?utf-8\?Q\?\=C5\=BBenczykowski\=22's\?\= message of "Thu, 21 Dec 2017 13:06:05 -0800") Message-ID: <87wp1foiwa.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=1eS8eV-0000OR-SG;;;mid=<87wp1foiwa.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.133.177;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+9oQNXxGb1MDDzWplLZK+79nbR8m/3iXk= X-SA-Exim-Connect-IP: 67.3.133.177 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 * 2.5 XMWhlSbjSex Whole Obfuscated Subjects * 0.7 XMSubLong Long Subject * 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.4692] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: =?ISO-8859-1?Q?***;Maciej =c5=bbenczykowski ?= X-Spam-Relay-Country: X-Spam-Timing: total 685 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.3 (0.5%), b_tie_ro: 2.2 (0.3%), parse: 1.56 (0.2%), extract_message_metadata: 6 (0.8%), get_uri_detail_list: 2.6 (0.4%), tests_pri_-1000: 7 (1.0%), tests_pri_-950: 2.5 (0.4%), tests_pri_-900: 1.97 (0.3%), tests_pri_-400: 30 (4.3%), check_bayes: 27 (4.0%), b_tokenize: 11 (1.6%), b_tok_get_all: 7 (1.0%), b_comp_prob: 3.6 (0.5%), b_tok_touch_all: 2.6 (0.4%), b_finish: 0.92 (0.1%), tests_pri_0: 603 (88.1%), check_dkim_signature: 0.98 (0.1%), check_dkim_adsp: 6 (0.8%), tests_pri_500: 8 (1.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] userns: honour no_new_privs for cap_bset during user ns creation/switch 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 Content-Length: 1837 Lines: 46 Maciej Żenczykowski writes: > From: Maciej Żenczykowski > > This allows locking down user namespaces tighter, > and it could even be considered a security fix. No. This makes no logical sense. A task that enters a user namespace loses all capabilities to everything outside of the user namespace. Capabilities inside a user namespace are only valid for objects created inside that user namespace. So limiting capabilities inside a user namespace when the capability bounding set is already fully honored by not giving the processes any of those capabilities makes no logical sense. If the concern is kernel attack surface versus logical permissions we can look at ways to reduce the attack surface but that needs to be fully discussed in the change log. > Signed-off-by: Maciej Żenczykowski > --- > kernel/user_namespace.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c > index 246d4d4ce5c7..2354f7ade78a 100644 > --- a/kernel/user_namespace.c > +++ b/kernel/user_namespace.c > @@ -50,11 +50,12 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns) > * anything as the capabilities are bound to the new user namespace. > */ > cred->securebits = SECUREBITS_DEFAULT; > + cred->cap_bset = task_no_new_privs(current) ? current_cred()->cap_bset > + : CAP_FULL_SET; > cred->cap_inheritable = CAP_EMPTY_SET; > - cred->cap_permitted = CAP_FULL_SET; > - cred->cap_effective = CAP_FULL_SET; > + cred->cap_permitted = cred->cap_bset; > + cred->cap_effective = cred->cap_bset; > cred->cap_ambient = CAP_EMPTY_SET; > - cred->cap_bset = CAP_FULL_SET; > #ifdef CONFIG_KEYS > key_put(cred->request_key_auth); > cred->request_key_auth = NULL;