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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18CEAEB64D7 for ; Wed, 28 Jun 2023 19:31:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AEAF58D0007; Wed, 28 Jun 2023 15:31:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A9AFF8D0001; Wed, 28 Jun 2023 15:31:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 963748D0007; Wed, 28 Jun 2023 15:31:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8823B8D0001 for ; Wed, 28 Jun 2023 15:31:34 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2420A1C8D58 for ; Wed, 28 Jun 2023 19:31:34 +0000 (UTC) X-FDA: 80953150908.10.369B6C9 Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) by imf28.hostedemail.com (Postfix) with ESMTP id 6BAEEC0028 for ; Wed, 28 Jun 2023 19:31:31 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=codewreck.org header.s=2 header.b=fLAUaL3z; dkim=pass header.d=codewreck.org header.s=2 header.b=EMNt9hc0; spf=pass (imf28.hostedemail.com: domain of asmadeus@codewreck.org designates 91.121.71.147 as permitted sender) smtp.mailfrom=asmadeus@codewreck.org; dmarc=pass (policy=none) header.from=codewreck.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687980692; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kq+Cd3ze4IdymcmcbBkmObHA4RqjoJ5x5Sn/8OiQZFM=; b=HlhTes98p5POhph+ZpYehYmThT27Nqcsxsep62MjdDnZPtp6UBNrgMt6TwMEtfsqWZTZgD PgZBxiGZUFuO2K6b9k1c0W7c9cS8OHY/+neFtmpvUi793AiI58Y5zgAsjisV7cwcdXa5m9 2g/SGiQ2HmSyaT54bJG0D2k6ivRrpPA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687980692; a=rsa-sha256; cv=none; b=okTH+/J1/rVeVE/zqCIo9HHhuJ03lCaHFHl8NIQblQ8Xkv67zVYp2eRs8YJjFKPHPm2pe3 tnaGOgeCk/gwfma0e/qAqZNKkFrqZ++pcbJ73hF17cUzBLwJfI+cZGreX5I2zv8b0BRFax fm/wi5IfKZEfjKPOTD4+znAp+vVzNnA= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=codewreck.org header.s=2 header.b=fLAUaL3z; dkim=pass header.d=codewreck.org header.s=2 header.b=EMNt9hc0; spf=pass (imf28.hostedemail.com: domain of asmadeus@codewreck.org designates 91.121.71.147 as permitted sender) smtp.mailfrom=asmadeus@codewreck.org; dmarc=pass (policy=none) header.from=codewreck.org Received: by nautica.notk.org (Postfix, from userid 108) id 6BB59C01E; Wed, 28 Jun 2023 21:31:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1687980689; bh=kq+Cd3ze4IdymcmcbBkmObHA4RqjoJ5x5Sn/8OiQZFM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fLAUaL3zge/w0oyouSmSkjTKt4CPQh1/XcyOrs000ItkQlF5pJXSZAeQeO6S8YfFk FZnS3VHrFKvpzVvlebSpbtZT6JeRO6YGvIFH5oAzlGMvBV9R1OCtw3mFvj1uNO97lz C/08VbTIzlXtW2+3NUjk+M0zue7dwsWn0SjJPfC6WhH5B0lDCIFsWU0p5GOq/FxbgN 8IlqzOhCjU2Zb2VHLTMVLzesAArWsD1HSyxX2Q3LkDKFMvpp5uhe/GG5QiSq4o9PEr XnYYdUEWHJx3fhKmocRcbKwLcM17Gi+pIm6/9UOpNQkhDVe3BaEF01J2RvrAmx6YQW jd97PAO36/OHw== Received: from odin.codewreck.org (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id ECF89C009; Wed, 28 Jun 2023 21:31:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1687980688; bh=kq+Cd3ze4IdymcmcbBkmObHA4RqjoJ5x5Sn/8OiQZFM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EMNt9hc06DX1WRZOck1lTPJyOqIRq9yDZk7fUqoltSw8y+VnEhMBu4TKwazeDtCO1 +l+FT3MgGR99zwdb/VjlTSTdob2EnGmbDOKDLaTKkqLDoPQiMbjInagFrVuc5VRbP5 2rPzy6I1H4vB1GhtUJU3PhwpShEdJrNhVkgwLc7c5qt9OEh0wcCzBfPb5yXI9YO8c0 SDT9K9Rkk6UjwbejplGA1QTjnGRz87ur7z4SbqcGp2BvnxYU5dqPIujFl/23AKcS0K SsTzEOX/VTG9PfBZdx0P+sG5UGOf65DUx7iHfe2EytyNFSd4gI8l5ccR/H3IHBiUvv rY9Ebd/9RROPg== Received: from localhost (odin.codewreck.org [local]) by odin.codewreck.org (OpenSMTPD) with ESMTPA id 4821f3bd; Wed, 28 Jun 2023 19:31:21 +0000 (UTC) Date: Thu, 29 Jun 2023 04:31:05 +0900 From: Dominique Martinet To: jeffxu@chromium.org Cc: skhan@linuxfoundation.org, keescook@chromium.org, akpm@linux-foundation.org, dmitry.torokhov@gmail.com, dverkamp@chromium.org, hughd@google.com, jeffxu@google.com, jorgelo@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, linux-hardening@vger.kernel.org, linux-security-module@vger.kernel.org, kernel test robot Subject: Re: [PATCH v8 3/5] mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC Message-ID: References: <20221215001205.51969-1-jeffxu@google.com> <20221215001205.51969-4-jeffxu@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 6BAEEC0028 X-Rspam-User: X-Stat-Signature: j67cfn6i5bugdo6e775ygzohxwf5tepm X-Rspamd-Server: rspam03 X-HE-Tag: 1687980691-116431 X-HE-Meta: U2FsdGVkX18vztd83q9MwsiZglrgtj91kSMqAr3a3SC2L20lABe2LGLOBO26qAOrj0eea/hWB4Xo4cdID7rDqq8PPGAv0JuRseIa6QyIkTJbLW3S4dWJAYYRJPEB+AuSlivjnfZYArX7BglcwiO9LQGBnt76CmPWCFA/hqF1LSsfkK7YfRO1TmuUB91Z1j891rEuW1WRSLpdHUpyPjPiM3+tIz0mUPmvCgvA5+aJRw/YJfqdhxFYg5IwLBhHIrDWTm/pfXUgMN/5AR3aUB4M913GSoOCfKyR1SxMLJYFin2Xd8B5irHIJY2yApvkjqP7H0e12Cmw/iI9V+XXvM8qp4EDztRhvkaPJjDwqksmEbDw5Mo4cnwIhV2OOKo1irl9l6WUnKe762Ta3BMH/w2oXJsASL5323+rQniSChuu9mFm5T0SwdLi2Y3F9OFwbN2TFh6+3yyFNs7+OexCK9oAZ+Zoky1fyGdel5XLO9vrqie/YbaJ6Vmc/L4I6Gt+UOQME1PmyhyZcSRsFWfdJPfyuSSh4Bf+eCIeCgAQ/iG3DR7cRAhIxFVR11xKbCdzUPmy5nBZs9LoRdM+0uwoikU2Xr9bAqw880MrwjSVVb/SdiKAXLq0LAYDf/BKp+42T1cVUc+UQCmCqQwwMkpTaJzbNjbsSFCgbQNICEISVPuNtdNwL+B/8tqq2iM1JTyyy/ADbdglju4+XKIVqwBG7lLktBtCIK1voY0d863m3APQYR23Q07V3dNxSKX8fcJuHNVwaKKoAjILlXXPcKjFq1vuC6G65D1KwkYRCAjqvMyej6IsgW/kh5c94rDTZL/IBo39n5vZ5zWO/3aa9ZX650EBVxCxzKBp0DZLLk/cXHhThFAE58YfcpY4jv9WP8DXa7JPKIfJSl1T55/uV/OHecoLsXhMt4hR8coNvJgCn8XPB+T/mnK1hqu1CoCd6cPeixag1bIJ0ywDrgdUWCM64eM h7WxK+NW 4zJ1f5f82usMdjJo29g4k731AMg9eBf4iEtZdDqmGxAVLBz3xV/GtbJzEvKgBfrlNIK0Qo9AhR44t5IRtJp5l7yYSlfo3uEkHkk/9tZqdnKwUehr+KyJ2spgDMzkhKHIXuUw8DFgT4Esz6wHiV0tUP6F31n6ZcjH0m/V28Vde6Z0xI3gW0QPybV3i9Eti0E9FH87+va0S30oHy1M6OH17n7aK94Eg/pTCU9Bu/8G+K+xC9XVvdbca+vDmqu9D+BRqQAOl3rqApvoEke9UIUy0R/4eDQDb6n9Ne0t8 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Dominique Martinet wrote on Wed, Jun 28, 2023 at 08:42:41PM +0900: > If flags already has either MFD_EXEC or MFD_NOEXEC_SEAL, you don't check > the sysctl at all. > [...repro snipped..] > > What am I missing? (Perhaps the intent is just to force people to use the flag so it is easier to check for memfd_create in seccomp or other LSM? But I don't see why such a check couldn't consider the absence of a flag as well, so I don't see the point.) > BTW I find the current behaviour rather hard to use: setting this to 2 > should still set NOEXEC by default in my opinion, just refuse anything > that explicitly requested EXEC. And I just noticed it's not possible to lower the value despite having CAP_SYS_ADMIN: what the heck?! I have never seen such a sysctl and it just forced me to reboot because I willy-nilly tested in the init pid namespace, and quite a few applications that don't require exec broke exactly as I described below. If the user has CAP_SYS_ADMIN there are more container escape methods than I can count, this is basically free pass to root on main namespace anyway, you're not protecting anything. Please let people set the sysctl to what they want. > Sure there's a warn_once that memfd_create was used without seal, but > right now on my system it's "used up" 5 seconds after boot by systemd: > [ 5.854378] memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=1 'systemd' > > And anyway, older kernels will barf up EINVAL when calling memfd_create > with MFD_NOEXEC_SEAL, so even if userspace will want to adapt they'll > need to try calling memfd_create with the flag once and retry on EINVAL, > which let's face it is going to take a while to happen. > (Also, the flag has been added to glibc, but not in any release yet) > > Making calls default to noexec AND refuse exec does what you want > (forbid use of exec in an app that wasn't in a namespace that allows > exec) while allowing apps that require it to work; that sounds better > than making all applications that haven't taken the pain of adding the > new flag to me. > Well, I guess an app that did require exec without setting the flag will > fail in a weird place instead of failing at memfd_create and having a > chance to fallback, so it's not like it doesn't make any sense; > I don't have such strong feelings about this if the sysctl works, but > for my use case I'm more likely to want to take a chance at memfd_create > not needing exec than having the flag set. Perhaps a third value if I > cared enough... -- Dominique Martinet | Asmadeus