From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8BE8C77B7A for ; Fri, 2 Jun 2023 00:07:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233015AbjFBAHA (ORCPT ); Thu, 1 Jun 2023 20:07:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229884AbjFBAG6 (ORCPT ); Thu, 1 Jun 2023 20:06:58 -0400 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6773D1 for ; Thu, 1 Jun 2023 17:06:56 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]:37446) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1q4sJh-00Evgz-Q9; Thu, 01 Jun 2023 18:06:53 -0600 Received: from ip68-110-29-46.om.om.cox.net ([68.110.29.46]:32956 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1q4sJg-003GZB-ML; Thu, 01 Jun 2023 18:06:53 -0600 From: "Eric W. Biederman" To: ~akihirosuda Cc: linux-kernel@vger.kernel.org, containers@lists.linux.dev, serge@hallyn.com, brauner@kernel.org, paul@paul-moore.com, ~akihirosuda , akihiro.suda.cz@hco.ntt.co.jp References: <168547265011.24337.4306067683997517082-0@git.sr.ht> Date: Thu, 01 Jun 2023 19:06:27 -0500 In-Reply-To: <168547265011.24337.4306067683997517082-0@git.sr.ht> (akihirosuda@git.sr.ht's message of "Tue, 30 May 2023 18:50:50 +0000") Message-ID: <87v8g6bud8.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1q4sJg-003GZB-ML;;;mid=<87v8g6bud8.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.110.29.46;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX19jCAD3VXiN6cfDqTILsJT4KFsn1CUFU9Y= X-SA-Exim-Connect-IP: 68.110.29.46 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH linux 0/3] [PATCH] userns: add sysctl "kernel.userns_group_range" X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ~akihirosuda writes: > This sysctl limits groups who can create a new userns without > CAP_SYS_ADMIN in the current userns, so as to mitigate potential kernel > vulnerabilities around userns. > > The sysctl value format is same as "net.ipv4.ping_group_range". > > To disable creating new unprivileged userns, set the sysctl value to "1 > 0" in the initial userns. > > To allow everyone to create new userns, set the sysctl value to "0 > 4294967294". This is the default value. > > This sysctl replaces "kernel.unprivileged_userns_clone" that is found in > Ubuntu [1] and Debian GNU/Linux. > > Link: https://git.launchpad.net/~ubuntu- > kernel/ubuntu/+source/linux/+git/jammy/commit?id=3422764 [1] > > Signed-off-by: Akihiro Suda How does this functionally differ from what already exists user.max_user_namespaces? Given that setns exists I don't see limiting creation of user namespaces by group being meaningful, if your goal is to reduce the attack surface of the kernel to mitigate potential kernel vulnerabilities. How does this functionality interact with the use of setgroups in a user namespace? What is the value of a group_range inside of a newly created user namespace? How does that work to maintain the policy you are trying to implement? Eric