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 7758AC25B74 for ; Sun, 2 Jun 2024 09:46:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C31976B009A; Sun, 2 Jun 2024 05:46:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BDF4F6B009E; Sun, 2 Jun 2024 05:46:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A80B26B00A0; Sun, 2 Jun 2024 05:46:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8BC096B009A for ; Sun, 2 Jun 2024 05:46:07 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1064CA039A for ; Sun, 2 Jun 2024 09:46:07 +0000 (UTC) X-FDA: 82185467574.06.3978660 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by imf20.hostedemail.com (Postfix) with ESMTP id 15A451C000C for ; Sun, 2 Jun 2024 09:46:04 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=cyphar.com header.s=MBO0001 header.b="ZFmM/uM9"; spf=pass (imf20.hostedemail.com: domain of cyphar@cyphar.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=cyphar@cyphar.com; dmarc=pass (policy=reject) header.from=cyphar.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717321565; a=rsa-sha256; cv=none; b=SOYAJZef3hoJeuHLSJfKpixyOh6Fl+UTD1VqGd/kAe7GxY2YlvvGXKsqdE8EF2vrFKgXrU XiUOZUASHLpRteb7+sRISMvH0sx4B1q/aLXvHcJIkc9YL6AIQwmN4K35SpjRdvtWuz+Lbw fBqw7r9i/FD9LSy8TE8WuFVH5ME4omg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=cyphar.com header.s=MBO0001 header.b="ZFmM/uM9"; spf=pass (imf20.hostedemail.com: domain of cyphar@cyphar.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=cyphar@cyphar.com; dmarc=pass (policy=reject) header.from=cyphar.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717321565; 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=4MGu+gYZhHiqQdLEwANI+Rx5K32ShCShDlDKn8KZM4I=; b=tnmhSyOGXNd1EGBNeghK/soLCEilvmJi/1TNhXQ9/c7tt+osz68hAzL2znQSsWrJVMLAJ4 QGrui7ZCkU4hXxCYexS/R80CbqYtrkx7g5HbUdgdYnE3VeFnzYUwSJbGZIyRhNeFopg/Ho nmII9QmERfEAOKqqKNDIC2iO4fZCwPA= Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4VsX6b6bGRz9sbl; Sun, 2 Jun 2024 11:45:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cyphar.com; s=MBO0001; t=1717321559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4MGu+gYZhHiqQdLEwANI+Rx5K32ShCShDlDKn8KZM4I=; b=ZFmM/uM9aQEG5iqhB8sZv+w10ZBsfRncNOSL2unXs6RzGq/blznplwjgtysGSuruIFy30B ooPcAByTguqi7yXwAmEZnhm8nBclfdQP6O2Cen8zOdI5B2vJ70gBg8SNKx3DGuk6Ibzzct /GozljH3xX/ItFtWaJbDdxiY8q24KbHeExCQJz5k7xfe1hUiEO9OjwiOjFl8ZblIu6uQ0p KFqs6maZ3e+E+NEmBuVrMuc32kxUINiyHvUt7x0NYyZrdubL3pxu93gSi1+8xNhRpmF2aZ S6p7jAdCxR1cxll1LiEVESfy6Q/OKDw6nYyvQCgWQKneDmlBd9aZ9V9pWcCiFA== Date: Sun, 2 Jun 2024 02:45:44 -0700 From: Aleksa Sarai To: Jeff Xu Cc: Jeff Xu , David Rheinsberg , =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, dmitry.torokhov@gmail.com, Daniel Verkamp , hughd@google.com, jorgelo@chromium.org, skhan@linuxfoundation.org, Kees Cook Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING` Message-ID: <20240602.091422-rusty.lint.soft.almond-nzWkHp0rBUnx@cyphar.com> References: <20240513191544.94754-1-pobrn@protonmail.com> <20240522162324.0aeba086228eddd8aff4f628@linux-foundation.org> <1KDsEBw8g7ymBVpGJZp9NRH1HmCBsQ_jjQ_jKOg90gLUFhW5W6lcG-bI4-5OPkrD24RiG7G83VoZL4SXPQjfldsNFDg7bFnFFgrVZWwSWXQ=@protonmail.com> <08450f80-4c33-40db-886f-fee18e531545@app.fastmail.com> <20240524.160158-custard.odds.smutty.cuff-caukvmB4EWP9@cyphar.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nsxvarx63lbmw3nq" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 15A451C000C X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: nec95xdfk7ijsu47eref5gtr9s4d946o X-HE-Tag: 1717321564-266091 X-HE-Meta: U2FsdGVkX19/pSW/95gcBtolAe1s4eDTWzIdFhIfuy9htNZdzvVqZjyVfbXGtdqHtjoFpJGiS3+ZU6SYx2oYYJw5EXULlYb8RGU8clK3qXSPNTSZ+3hRr91+H2sqQMsrrbhyUiAtjXFfact3R+iEPSavZUIjOpMRzDWN6AJFotFjN0DWEk+8m0s1ldDLufww7fdcN17pOLlj36ZB4DDXJDkKiVtCpTTGMV9IO2OMnAoGpFLqWSISHScE0uMWbKaNMY0Us+xMLbBHvc1HhdrlnE3i1xsAlyPoarCim5nctUFpOAqasxNXjljw+2sVZYHHZiOI08gj3SVVjbZuJt8QgA1jnXxcuKOkxBe4a5DxmDgkj9aKJ8fsOWEOeWQtLN66QLyRUUd6xbTefN6bw5NNgfJyrjejT6ubntU9A29/5KywJqVUgLUHRwYDATkGG2Hju7LhA0U05+REi3+4pRAYXHpFAQOjg3HZYw2220ibqa3nLikyYEZTvSookYPXPY0k4lmUCxeT5ZbZ614OLAHm4d46OGbFm5TpieD4CmYZaLjb6JhBSRrKIuz1hnn2OU5fsm2D7LMOQXd3Fdbyngyn9WCWeS670yEMpwVCt5ws4KP9s9I4rybeZpt3EZW9h4+LiRBTTKiRKA1fwkV/sS1z0OUGQpg6wGeriCnq+5b6Pauloak5et3Jw65XhLnIIU66pgjlJ4tP1X31IJTjnSmjF6n/hYuYDTh68/DAqCHdFJU2PjLiC0+UBpswmqUFWg1+suzqdw0NRTrVV5QZfL5L4Dj5r5FiapWK9QTw6iMosGcS4GzR+WEQWuNniBA22ocPF+U9PV3YJZqLYQUsT3xhGc3ZFp5oR+LsRpSjK+2J4Q8Hpcy61gPBYTeM7n47RpgU+Gm8i9j+RZekGBauea7CVPbihONfFeNrl/9rW4XVXqhWpjWWw3WgyhbOz6UP9ipfCly5UsQggVXgJKu61Zs doGzeNTK g/0NNEL2whGaPyobNBELiYHC/DZdPZqDuughEMIdE5w+ACK1fjMTH3jaEk6T04iFwHKyPfSPqvKXqvEQwetILExFFt+9sNkxyZ40ZfI8NENTdZA6Hah3Xgeee2BOpOBkknzgfPuSV8my7hWArGFyEMxlKGlyFeLN4E5wvnsjnIyQy/ohp3kFGGc92gu5QQV0LtNGIpS4cewk24uf0BXfnOsStAmTh6dKN7ugir7ObMmEdgH0hWFCN1lNEhFUCOTzNU6AfUzo50CJYnZZ5mGKgf9Osi0y9Irj6PPUk0qimKhrD8EQVYjelTjwONl3W3wyS9BCAKj31Nh/gVG2A34QvUEtOi3P3lfegpyGipd9L0T0bBFr5zYCaBJWO+FdpDXpc4CzUM5Rwmt20tw+4+7NPHASoIC1Uiuy/4QYjRUn8nrF4f004jDue7va6ed3KoXVEkRk4U19xmNT/5lzH6qgJn8x8fnjyKeAXmDDKuz5tX4Caevk= 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: List-Subscribe: List-Unsubscribe: --nsxvarx63lbmw3nq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024-05-28, Jeff Xu wrote: > Hi Aleksa, >=20 > On Fri, May 24, 2024 at 9:12=E2=80=AFAM Aleksa Sarai = wrote: > > > > On 2024-05-23, Jeff Xu wrote: >=20 > > > Regarding vm.memfd_noexec, on another topic. > > > I think in addition to vm.memfd_noexec =3D 1 and 2, there still cou= ld > > > be another state: 3 > > > > > > =3D0. Do nothing. > > > =3D1. This will add MFD_NOEXEC_SEAL if application didn't set EXEC or > > > MFD_NOEXE_SEAL (to help with the migration) > > > =3D2: This will reject all calls without MFD_NOEXEC_SEAL (the whole > > > system doesn't allow executable memfd) > > > =3D3: Application must set MFD_EXEC or MFD_NOEXEC_SEAL explicitly, or > > > else it will be rejected. > > > > > > 3 is useful because it lets applications choose what to use, and > > > forces applications to migrate to new semantics (this is what 2 did > > > before 9876cfe8). > > > The caveat is 3 is less restrictive than 2, so must document it clear= ly. > > > > As discussed at the time, "you must use this flag" is not a useful > > setting for a general purpose operating system because it explicitly > > disables backwards compatibility (breaking any application that was > > written in the past 10 years!) for no reason other than "new is better". > > > Are you referring to ratcheting in the sysctl in my original patch or > is this something else ? > I do not disagree with your change of "removing the ratcheting" from > the admin point of view. I'm referring to your original patch making vm.memfd_noexec=3D2 reject memfd_create() when called without MFD_EXEC or MFD_NOEXEC_SEAL (which is what every program written pre-mid-2023 did, since those flags didn't exist yet). This was fixed in 202e14222fad, and is separate to ratcheting (which was fixed in 9876cfe8ec1c). We definitely had a long discussion about it at the time. > > As I suggested when we fixed the semantics of vm.memfd_noexec, if you > > really want to block a particular flag from not being set, seccomp lets > > you do this incredibly easily without acting as a footgun for admins. >=20 > seccomp can but it requires more work for the container, e.g. > container needs to allow-list all the syscalls. If you're applying the rule for a single syscall you can create a deny-list, so no need for a full-on filter for everything. Also, most containers already have allow-list seccomp filters applied, so adjusting them to add a restriction for one syscall is not that complicated. > I'm trying to point out that seccomp might not cover all user-cases. One of the reasons I'm suggesting seccomp because I think that this "use-case" probably only exists within ChromeOS, and so adding more kernel infrastructure around it makes little sense. seccomp has effectively no performance overhead for something this simple and lets you block this if you really want to. For general purpose distributions and systems, an administrative knob to make working programs error out if they don't pass an effectively-noop flag to memfd_create(2) doesn't help pressure anyone into migrating because the random unmaintained program using memfd_create(2) isn't developed by the same company making the distribution... How would an admin setting vm.memfd_break_random_programs=3D1 help random_app_downloaded_from_the_internet get patched to use MFD_EXEC/MFD_NOEXEC_SEAL? (It doesn't.) > "ratcheting" in the vm.memfd_noexec is lightweight and can be applied > to the sandbox of the container in advance, but since admin doesn't > like ratcheting in sysctl, maybe prctl or LSM are ways to implement > such restriction. > > > Yes, vm.memfd_noexec can break programs that use executable memfds, but > > that is the point of the sysctl -- making vm.memfd_noexec break programs > > that don't use executable memfds (they are only guilty of being written > > before mid-2023) is not useful. > > > > In addition, making 3 less restrictive than 2 would make the original > > restriction mechanism useless. A malicious process could raise the > > setting to 3 and disable the "protection" (as discussed before, I really > > don't understand the threat model here, but making it possible to > > disable easily is pretty clearly). > > You could change the policy, but now > > you're adding more complexity for a feature that IMO doesn't really make > > sense in the first place. > > > The reason of 3 is help with migration (not for threat-model), e.g. a > container can force every apps run in the container migrates their > memfd_create to use either MFD_EXEC or MFD_NOEXEC_SEAL. This is the argument you had for the behaviour of vm.memfd_noexec=3D2 at the time. In the discussion we had last year, I explained that this is not "helpful" for the reasons explained above. There are plenty of old interfaces in Linux and we don't generally push people to migrate to newer interfaces, especially since in this case we're talking about a flag that is a no-op for the vast majority of programs on most systems. Only programs that need MFD_EXEC actually _need_ to switch (if distros eventually make vm.memfd_noexec=3D1 the default in a decade or two) and the most well-known programs that use MFD_EXEC have already been patched (runc is probably the most obvious one, and we patched this last year). Not to mention that a lot of programs that are maintained have already switched to the mostly-noop MFD_NOEXEC_SEAL, so the only programs that would be affected by this migration "help" would be older programs that won't be pressured to update because they're unmaintained. > But I understand what you mean, with current code, adding 3 would > cause more confusion to vm.memfd_noexec. Perhaps a new sysctl or prctl > is the way to go if the app wants to force migration. > In the hinder sight: two sysctls would work betters: the first deal > with migration, the second enforces NO_EXEC_SEAL. The "help with migration" feature shouldn't exist, and I removed it in 9876cfe8ec1c for a reason. --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --nsxvarx63lbmw3nq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQS2TklVsp+j1GPyqQYol/rSt+lEbwUCZlw/SAAKCRAol/rSt+lE b6A4AP9fzI5YnQ1cBUbCzMflLGqWUZpRUakBfO3/Jz7O67iKtQD+I9fniZeHnJ/i Wv8Omud46bsFJbnEyO1ZrAiM2HXO+Aw= =ZDBf -----END PGP SIGNATURE----- --nsxvarx63lbmw3nq--