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 56AD5C28B2B for ; Wed, 17 Aug 2022 15:08:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240774AbiHQPIl (ORCPT ); Wed, 17 Aug 2022 11:08:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240632AbiHQPId (ORCPT ); Wed, 17 Aug 2022 11:08:33 -0400 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B203E9C8CE; Wed, 17 Aug 2022 08:08:31 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]:37894) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oOKei-006IBh-F4; Wed, 17 Aug 2022 09:08:28 -0600 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:57490 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1oOKeg-004bdV-9U; Wed, 17 Aug 2022 09:08:28 -0600 From: "Eric W. Biederman" To: Linus Torvalds Cc: Frederick Lawler , kpsingh@kernel.org, revest@chromium.org, jackmanb@chromium.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, kafai@fb.com, songliubraving@fb.com, yhs@fb.com, john.fastabend@gmail.com, jmorris@namei.org, serge@hallyn.com, stephen.smalley.work@gmail.com, eparis@parisplace.org, shuah@kernel.org, brauner@kernel.org, casey@schaufler-ca.com, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, kernel-team@cloudflare.com, cgzones@googlemail.com, karl@bigbadwolfsecurity.com, tixxdz@gmail.com, Paul Moore References: <20220815162028.926858-1-fred@cloudflare.com> Date: Wed, 17 Aug 2022 10:07:50 -0500 In-Reply-To: (Paul Moore's message of "Tue, 16 Aug 2022 17:51:12 -0400") Message-ID: <8735dux60p.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=1oOKeg-004bdV-9U;;;mid=<8735dux60p.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=softfail X-XM-AID: U2FsdGVkX1+M/EzBB2yHTS3inlqfrtzf1DGaD1mEXx4= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v5 0/4] Introduce security_create_user_ns() X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org > > I just merged this into the lsm/next tree, thanks for seeing this > through Frederick, and thank you to everyone who took the time to > review the patches and add their tags. > > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git next Paul, Frederick I repeat my NACK, in part because I am being ignored and in part because the hook does not make technical sense. Linus I want you to know that this has been put in the lsm tree against my explicit and clear objections. My request to talk about the actual problems that are being address has been completely ignored. I have been a bit slow in dealing with this conversation because I am very much sick and not on top of my game, but that is no excuse to steam roll over me, instead of addressing my concerns. This is an irresponsible way of adding an access control to user namespace creation. This is a linux-api and manpages level kind of change, as this is a semantic change visible to userspace. Instead that concern has been brushed off as different return code to userspace. For observably this is a terrible LSM interface because there is no pair with user namespace destruction, nor is their any ability for the LSM to allocate any state to track the user namespace. As there is no patch actually calling audit or anything else observably does not appear to be a driving factor of this new interface. The common scenarios I am aware of for using the user namespace are: - Creating a container. - Using the user namespace to sandbox your application like chrome does. - Running an exploit. Returning an error code in the first 2 scenarios will create a userspace regression as either userspace will run less securely or it won't work at all. Returning an error code in the third scenario when someone is trying to exploit your machine is equally foolish as you are giving the exploit the chance to continue running. The application should be killed instead. Further adding a random failure mode to user namespace creation if it is used at all will just encourage userspace to use a setuid application to perform the namespace creation instead. Creating a less secure system overall. If the concern is to reduce the attack surface everything this proposed hook can do is already possible with the security_capable security hook. So Paul, Frederick please drop this. I can't see what this new hook is good for except creating regressions in existing userspace code. I am not willing to support such a hook in code that I maintain. Eric