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 66655C77B7A for ; Fri, 2 Jun 2023 00:14:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233061AbjFBAOU convert rfc822-to-8bit (ORCPT ); Thu, 1 Jun 2023 20:14:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229545AbjFBAOS (ORCPT ); Thu, 1 Jun 2023 20:14:18 -0400 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51EB912C for ; Thu, 1 Jun 2023 17:14:17 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]:38966) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1q4sQp-00Ew6R-PT; Thu, 01 Jun 2023 18:14:15 -0600 Received: from ip68-110-29-46.om.om.cox.net ([68.110.29.46]:54766 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 1q4sQo-003HU4-La; Thu, 01 Jun 2023 18:14:15 -0600 From: "Eric W. Biederman" To: Paul Moore Cc: "~akihirosuda" , linux-kernel@vger.kernel.org, containers@lists.linux.dev, serge@hallyn.com, brauner@kernel.org, akihiro.suda.cz@hco.ntt.co.jp References: <168547265011.24337.4306067683997517082-0@git.sr.ht> Date: Thu, 01 Jun 2023 19:14:08 -0500 In-Reply-To: (Paul Moore's message of "Tue, 30 May 2023 17:58:48 -0400") Message-ID: <87fs7abu0f.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; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1q4sQo-003HU4-La;;;mid=<87fs7abu0f.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: U2FsdGVkX19DIiVSRQ5BpipU+RbDjDyU5NgJlxnB9UQ= 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 Paul Moore writes: > On Tue, May 30, 2023 at 2:50 PM ~akihirosuda wrote: >> >> 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] > > Given the challenges around adding access controls to userns > operations, have you considered using the LSM support that was added > upstream last year? The relevant LSM hook can be found in commit > 7cd4c5c2101c ("security, lsm: Introduce security_create_user_ns()"), Paul how have you handled the real world regression I reported against chromium? Paul are you aware that the LSM hook can not be used to achieve the objective of this patchset? > and although only SELinux currently provides an access control > implementation, there is no reason you couldn't add support for your > favorite LSM, or even just a simple BPF LSM to enforce the group > controls as you've described them here. Is there a publicly available SELinux policy that uses that LSM hook? Eric