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 39C91C433F5 for ; Thu, 6 Oct 2022 14:42:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231594AbiJFOmP (ORCPT ); Thu, 6 Oct 2022 10:42:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbiJFOmO (ORCPT ); Thu, 6 Oct 2022 10:42:14 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36596A99F1; Thu, 6 Oct 2022 07:42:13 -0700 (PDT) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 296Eg7p8007809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Oct 2022 10:42:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1665067329; bh=S2x0j0IMfjyHgJEcjGYF7+KaBoxh4wuOGf7JhVXcjJo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=IAetTbAqYiQV5GylQ6WUizemjFS+jog/L9doNU8rV1tn1SFK4r+vhdrTOuUbuuTls /U4G0xPiXz3Efu1pjUVi/u1wG4K59l/gzv8CIZcFlm6VJYZgCMNzCJ60Ua6CzFSz6k 67oJH2lffqyMwBwcIq45kzrg1sOPD8Z/qUFpxUv8qHaXCQ6l+5bcQOqtMgvXxyzf1+ IqQI6XJTIk6E43ucxFDSGppkCM/oC5RcFyg2cC4sLZzQU4yt40/I4I5FBU63FNYlJG AW70mHa+Fy4eOaL1gGNTymqHZL/kG5njC61rbKVGKgeJPDBpS70BFklh37zhZYvlcx icsaTZmBTvS0Q== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 6CF8715C35F2; Thu, 6 Oct 2022 10:42:07 -0400 (EDT) Date: Thu, 6 Oct 2022 10:42:07 -0400 From: "Theodore Ts'o" To: "Eric W. Biederman" Cc: Linus Torvalds , Paul Moore , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] LSM patches for v6.1 Message-ID: References: <87sfk3mim9.fsf@email.froward.int.ebiederm.org> <87r0zmigx6.fsf@email.froward.int.ebiederm.org> <87h70h5d36.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h70h5d36.fsf@email.froward.int.ebiederm.org> Precedence: bulk List-ID: Eric, there's one thing I don't get about why you hate LSM's having the ability to prevent user name spaces, and yet you are OK with (indeed, touting) /proc/sys/user/max_user_namespaces. If we set max_user_namespaces to N, won't the N+1'th application get an error when they try to create a user namespace? One of your arguments about why having LSM's forcing a error of say, EPERM, is that applications that don't check for error returns might get confused. (Those are buggy applications; so they should be fixed --- isn't that your argument about why we shouldn't be freaking out over security bugs caused by kernel bugs and user namespaces.) But if you set max_user_namespaces, that same application will now fail with say, ENOSPC. And if in fact there is a buggy application that will create a security exposure because they aren't checking !@#@?! error returns, an attacker can simply create N user namespaces --- and then trigger the buggy applicaion, at which point, they will have 0wned the system. - Ted