Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2293407rwb; Wed, 5 Oct 2022 11:57:08 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7O0JfppdoQr22758WWI2avq/JvzIHOOC5FTGPEVQ6iV7xJMxqNfTSwODi67YmuGBf0xyk/ X-Received: by 2002:a63:ed0e:0:b0:457:4a30:cb8c with SMTP id d14-20020a63ed0e000000b004574a30cb8cmr1020409pgi.161.1664996228276; Wed, 05 Oct 2022 11:57:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664996228; cv=none; d=google.com; s=arc-20160816; b=zS05MH/opm3bgA5q7BIKbRmo/qLieR18T1vzr4VtHKIQ2Lu6i4GdJFkVnSxyW5XbbA 2vEGhoKr7uG20+AVylBvlHUx745ZuT8LdC/uUZSlJ9J9iYhLDO8h1c/TlpqUPO3pUP5l pAuaCMholItO0VHZlkCQwwXikIDP+5fcz1FlyHSzcN5lNmNR2FPIbKgsUScYLmVzdGF4 lhtabig7He831l0HhkLhuaX4wHQ2wGIKv2AocY61eWB/RSrPwi0z5kt4eeygokpKCA4V M+AUH7NQydUtzhIN2EdSkMOWXSjNK1GYNuGyUfT8ih06h+uWRtYaWrsqVmIZIAixzW1U CKDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=qFz8bcXSm8NKx+cQ2WBeXMjTdSUy3qZJoPO+EKQrt+k=; b=P4OfFD0Q0+h7D7FJ3wksduT4lBidJyTQw04BfA6F0awKJxSy73xmDYXeBqrNNHokom 9I6yxPPh8r0LqreJAv/syb6N+24OyUwYUCeUABxiHWi2lLR8WyRlZHlnw87ZPrpbh7wo XpkGq1FfkakS6km4IWvjOF4u5Ojgkq+FcjZYCz/nW1Fv2OxfAR5ZFsoQqeO+FDAZVCdW CVery0Z4t2ZVmV3SXOVuUHtFx7ourJOwAOdDqLQcNYe5zn2s5KQ6/6qelCpQ64Oq02n9 UrLXYFlBINuuNGpfdj2qIv4edBGg+JqvJqpd5c68ivjvsa8wFIOui8UkEjIJ49NuDYA6 qxbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=NgFXCEoO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u69-20020a637948000000b0042ac5a24f3fsi17450658pgc.493.2022.10.05.11.56.49; Wed, 05 Oct 2022 11:57:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=NgFXCEoO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231147AbiJESy7 (ORCPT + 99 others); Wed, 5 Oct 2022 14:54:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231226AbiJESyy (ORCPT ); Wed, 5 Oct 2022 14:54:54 -0400 Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [IPv6:2001:4860:4864:20::2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3BA6318B06 for ; Wed, 5 Oct 2022 11:54:51 -0700 (PDT) Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-132e9bc5ff4so1852004fac.7 for ; Wed, 05 Oct 2022 11:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qFz8bcXSm8NKx+cQ2WBeXMjTdSUy3qZJoPO+EKQrt+k=; b=NgFXCEoOwxhznFgovrwNaSKvGa6GrTCOnIddMQRVCb83LQHPPOqAQigJIqyEA6Mu9U 2op2a7Ahuy/CUAf5CiVfnXr3zzMZQcbrbZ+Ya2KCsxmxB/NBv+f7R4h7bK3Db/Bb/ZhC mycMkLuYRZGr8SBQPoJVFxfkwMQN1keAVyeXI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qFz8bcXSm8NKx+cQ2WBeXMjTdSUy3qZJoPO+EKQrt+k=; b=mRYL2EWDTTpVY9cs/VfsOxAhkBAYNi9uj3+pqXVo0EPrswwaOer7+pyQb6uNsqMm7e edfRo81h8iUw1HqRpDR56EzLCOAToNqTdnBgxEtAT3gOvKDF/OzXbis+ut684sCz6N7y 8C6bJPdSeCpb/z7EtJOpGr3ZEwxm7LQgERip8vnHs+FEa7zRb5y6/5qgdJguXW1C5Zd3 UIGT3G+gvV+YyOFddF5QhtyAErV1CL5U4GxV7T6u2wpNfFDdohoVqGEJGHWegBg0VBs5 lzy+BtJiRcY5ydhE0ZH6vSl/LB5pADOj7zFTqExeZSRHL8/cmMrTk6pckGjK4lhw3Dom UlFw== X-Gm-Message-State: ACrzQf2CkVOTSGSXUvVxLwV6C2rFnFhoTqvnUVY7iv58x9qhNnfuFz4E IKbWYmuouxnQOllmyhOG+dcoX9LCf56znw== X-Received: by 2002:a05:6870:170e:b0:132:beae:87ec with SMTP id h14-20020a056870170e00b00132beae87ecmr589130oae.298.1664996089607; Wed, 05 Oct 2022 11:54:49 -0700 (PDT) Received: from mail-oa1-f44.google.com (mail-oa1-f44.google.com. [209.85.160.44]) by smtp.gmail.com with ESMTPSA id n6-20020a9d6f06000000b00660d73c8bdesm1461863otq.50.2022.10.05.11.54.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Oct 2022 11:54:48 -0700 (PDT) Received: by mail-oa1-f44.google.com with SMTP id 586e51a60fabf-1324e7a1284so12246863fac.10 for ; Wed, 05 Oct 2022 11:54:48 -0700 (PDT) X-Received: by 2002:a05:6870:c888:b0:12c:7f3b:d67d with SMTP id er8-20020a056870c88800b0012c7f3bd67dmr569402oab.229.1664996088058; Wed, 05 Oct 2022 11:54:48 -0700 (PDT) MIME-Version: 1.0 References: <87sfk3mim9.fsf@email.froward.int.ebiederm.org> <87r0zmigx6.fsf@email.froward.int.ebiederm.org> In-Reply-To: <87r0zmigx6.fsf@email.froward.int.ebiederm.org> From: Linus Torvalds Date: Wed, 5 Oct 2022 11:54:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] LSM patches for v6.1 To: "Eric W. Biederman" Cc: Paul Moore , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 5, 2022 at 5:39 AM Eric W. Biederman wrote: > > We already have /proc/sys/user/max_user_namespaces. It is a per userns > control so you can run it in as fine grain as you like. A little > cumbersome perhaps but real. It's not that it's cumbersome. It's that it is *USELESS*. Sure, it limits the memory footprint of somebody who does the fork-bomb equivalent of user namespaces, but that's the least of the problems. Just think of normal users. They'd want a limited number of user namespaces for things like sandboxing (whether google chrome or whatever). So distros do want to allow people a few of them. But they want to be able to do so in a *controlled* manner. Not a "ok, this user can create five user namespaces and do whatever they want in them". Because we've had the issues where some kernel part has gotten things wrong, and thought "local NS root means root" or similar. So it's not about the number of namespaces. AT ALL. It's about *who* and *what* does them. > I don't know. I tried to have the conversation and Paul shut it down. I really get the feeling that the problem here is that you're not even acknowledging the whole issue to begin with, since you mention that "max_user_namespaces" not once, but twice in the email. > It would be the easiest thing in the world in security_capable to > ask is this a trusted app, if not the answer is no. Isn't this *literally* what security_create_user_ns() would basically be doing? IOW, letting the LSM just say "this app is trusted to create a new user namespace". And that is what the LSM model is literally designed for. Because the kernel doesn't inherently know "I trust this app". It doesn't know the difference between "google-chrome" and "l33t-crack3r". It needs some kind of external set of rules. See? Linus