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 185A2C00140 for ; Mon, 8 Aug 2022 17:46:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25F048E0001; Mon, 8 Aug 2022 13:46:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20E066B0073; Mon, 8 Aug 2022 13:46:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D6048E0001; Mon, 8 Aug 2022 13:46:13 -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 F219A6B0072 for ; Mon, 8 Aug 2022 13:46:12 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C85B61A0B00 for ; Mon, 8 Aug 2022 17:46:12 +0000 (UTC) X-FDA: 79777154184.16.4594FFD Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf06.hostedemail.com (Postfix) with ESMTP id 6FB27180145 for ; Mon, 8 Aug 2022 17:46:11 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id x23so9188242pll.7 for ; Mon, 08 Aug 2022 10:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=WT0gvMZYO/av++KMudc6Dk4HO66L8Urniksc21Z/06c=; b=HqrXaad1rdwTwFVLqtIf2gsOjqqHSCtra1Op2I+Ip1+B6FPHxPEzwTFH7bXQwHcgET 670AgcycqxHJDRROfj5zyTe5NwQtZFhFxYR5FYTupki7enfM8YtWwCxJCV7/nQfmy4cJ IxrZhtFvvcJ66LqIrfUAMfkK7CmlRw5Rv0KXw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=WT0gvMZYO/av++KMudc6Dk4HO66L8Urniksc21Z/06c=; b=KEHa3Yn1dmRiU8lQg/et/rq3i5gqUtKkTySOsvIhD72y1/0z7MzXqFrxrTz3l6xaWz Lfdec5drGsM7bhvndIVHAl1dfC64WNXImwM0+oq7ZD7PdP7QwX6S6Qgg33C7eglTT2Xd 2iC54zosVloCPORSMyTpqbnqQ58aIu5GE5nf/73vDFzjpBZuXaWLZb2OfNWMfC4ibaZY bujWmBh+6qvN/YAga60wxskWnrTXG8B+uXznt7j0JvnQqi8ajx8CbEf3RZIugsaipvsJ N+xB+XyeltmAQCiXEgMOmrL+QsMceqpDNdyGHtSLHdq8uodP1kkfuon9e9yvpE1VXfU9 pXNQ== X-Gm-Message-State: ACgBeo10pKJpnvEof4F3Y3NFoRQ60X86gvMELWeUBifauC5Y4x2R8pOk 6Al8F6cawQ0Gh5K88i55NF7Iaw== X-Google-Smtp-Source: AA6agR55vq+x0LDDr8mxEbc8OnrHWhZtkoyD+AcW+LYABM9JFgkRs4j4RTu6F017ikC4JmT33xQogA== X-Received: by 2002:a17:90b:3c4c:b0:1f3:3d62:39e2 with SMTP id pm12-20020a17090b3c4c00b001f33d6239e2mr29906557pjb.88.1659980770387; Mon, 08 Aug 2022 10:46:10 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id d15-20020a17090ad98f00b001f200eabc65sm8394142pjv.41.2022.08.08.10.46.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Aug 2022 10:46:09 -0700 (PDT) Date: Mon, 8 Aug 2022 10:46:08 -0700 From: Kees Cook To: jeffxu@google.com Cc: skhan@linuxfoundation.org, akpm@linux-foundation.org, dmitry.torokhov@gmail.com, dverkamp@chromium.org, hughd@google.com, jorgelo@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, mnissler@chromium.org, jannh@google.com, Jeff Xu , linux-hardening@vger.kernel.org, Aleksa Sarai , dev@opencontainers.org, Christian Brauner Subject: Re: [PATCH v2 0/5] mm/memfd: MFD_NOEXEC for memfd_create Message-ID: <202208081018.9C782F184C@keescook> References: <20220805222126.142525-1-jeffxu@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220805222126.142525-1-jeffxu@google.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659980771; a=rsa-sha256; cv=none; b=C+U1WNswK9916WoaAQCuSBYe896dsESnomAzkpxgqamnjdVnPa0CIGIRnpHvC8jb40ZCdk fPeOxiySgif7Nfjf2mBi7ABFNUBmtfx/D+igDeW/cxL7vu3MzHOys45zKDzr7fAaimyPZt DEqFlDpG6Tounl2CuXTBQCWA8yAttvY= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HqrXaad1; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf06.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.182 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659980771; 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=WT0gvMZYO/av++KMudc6Dk4HO66L8Urniksc21Z/06c=; b=Do/yyJHai2koMPdDyxVTJsZDirZ7+3jg6ezhaW4TINTbyS5sXJrGBS9NwEmC/6tyI2z3SO PA/BwX+S6iVhemXB0QNuRsawmrCR44wwzGcfsOkJzravvL0D5+vJ+5ytSL9F5bxmQxpdin HPoWX1kroq3i4vm49aNyOz3oylCbs58= X-Rspamd-Server: rspam10 X-Stat-Signature: gefbzmpso713z7k5673kmjbsaikfebwz Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HqrXaad1; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf06.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.182 as permitted sender) smtp.mailfrom=keescook@chromium.org X-Rspam-User: X-Rspamd-Queue-Id: 6FB27180145 X-HE-Tag: 1659980771-321468 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: On Fri, Aug 05, 2022 at 10:21:21PM +0000, jeffxu@google.com wrote: > This v2 series MFD_NOEXEC, this series includes: > 1> address comments in V1 > 2> add sysctl (vm.mfd_noexec) to change the default file permissions > of memfd_create to be non-executable. > > Below are cover-level for v1: > > The default file permissions on a memfd include execute bits, which > means that such a memfd can be filled with a executable and passed to > the exec() family of functions. This is undesirable on systems where all > code is verified and all filesystems are intended to be mounted noexec, > since an attacker may be able to use a memfd to load unverified code and > execute it. I would absolutely like to see some kind of protection here. However, I'd like a more specific threat model. What are the cases where the X bit has been abused (e.g.[1])? What are the cases where the X bit is needed (e.g.[2])? With those in mind, it should be possible to draw a clear line between the two cases. (e.g. we need to avoid a confused deputy attack where an "unprivileged" user can pass an executable memfd to a "privileged" user. How those privileges are defined may matter a lot based on how memfds are being used. For example, can runc's use of executable memfds be distinguished from an attacker's?) > Additionally, execution via memfd is a common way to avoid scrutiny for > malicious code, since it allows execution of a program without a file > ever appearing on disk. This attack vector is not totally mitigated with > this new flag, since the default memfd file permissions must remain > executable to avoid breaking existing legitimate uses, but it should be > possible to use other security mechanisms to prevent memfd_create calls > without MFD_NOEXEC on systems where it is known that executable memfds > are not necessary. This reminds me of dealing with non-executable stacks. There ended up being three states: - requested to be executable (PT_GNU_STACK X) - requested to be non-executable (PT_GNU_STACK NX) - undefined (no PT_GNU_STACK) The first two are clearly defined, but the third needed a lot of special handling. For a "safe by default" world, the third should be "NX", but old stuff depended on it being "X". Here, we have a bit being present or not, so we only have a binary state. I'd much rather the default be NX (no bit set) instead of making every future (safe) user of memfd have to specify MFD_NOEXEC. It's also easier on a filtering side to say "disallow memfd_create with MFD_EXEC", but how do we deal with the older software? If the default perms of memfd_create()'s exec bit is controlled by a sysctl and the sysctl is set to "leave it executable", how does a user create an NX memfd? (i.e. setting MFD_EXEC means "exec" and not setting it means "exec" also.) Are two bits needed? Seems wasteful. MFD_I_KNOW_HOW_TO_SET_EXEC | MFD_EXEC, etc... For F_SEAL_EXEC, it seems this should imply F_SEAL_WRITE if forced executable to avoid WX mappings (i.e. provide W^X from the start). -Kees [1] https://bugs.chromium.org/p/chromium/issues/list?q=type%3Dbug-security%20memfd%20escalation&can=1 [2] https://lwn.net/Articles/781013/ -- Kees Cook