linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <jeffxu@google.com>
To: skhan@linuxfoundation.org
Cc: akpm@linux-foundation.org, dmitry.torokhov@gmail.com,
	dverkamp@chromium.org, hughd@google.com, jeffxu@google.com,
	jorgelo@chromium.org, keescook@chromium.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-mm@kvack.org, mnissler@chromium.org, jannh@google.com,
	Jeff Xu <jeffxu@chromium.org>
Subject: [PATCH v2 0/5] mm/memfd: MFD_NOEXEC for memfd_create
Date: Fri,  5 Aug 2022 22:21:21 +0000	[thread overview]
Message-ID: <20220805222126.142525-1-jeffxu@google.com> (raw)

From: Jeff Xu <jeffxu@chromium.org>

Hi,

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.

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 patch series adds a new MFD_NOEXEC flag for memfd_create(), which
allows creation of non-executable memfds, and as part of the
implementation of this new flag, it also adds a new F_SEAL_EXEC seal,
which will prevent modification of any of the execute bits of a sealed
memfd.

I am not sure if this is the best way to implement the desired behavior
(for example, the F_SEAL_EXEC seal is really more of an implementation
detail and feels a bit clunky to expose), so suggestions are welcome
for alternate approaches.

v1: https://lwn.net/Articles/890096/

Daniel Verkamp (4):
  mm/memfd: add F_SEAL_EXEC
  mm/memfd: add MFD_NOEXEC flag to memfd_create
  selftests/memfd: add tests for F_SEAL_EXEC
  selftests/memfd: add tests for MFD_NOEXEC

Jeff Xu (1):
  sysctl: add support for mfd_noexec

 include/linux/mm.h                         |   4 +
 include/uapi/linux/fcntl.h                 |   1 +
 include/uapi/linux/memfd.h                 |   1 +
 kernel/sysctl.c                            |   9 ++
 mm/memfd.c                                 |  39 ++++-
 mm/shmem.c                                 |   6 +
 tools/testing/selftests/memfd/memfd_test.c | 163 ++++++++++++++++++++-
 7 files changed, 221 insertions(+), 2 deletions(-)


base-commit: 9e2f40233670c70c25e0681cb66d50d1e2742829
-- 
2.37.1.559.g78731f0fdb-goog


             reply	other threads:[~2022-08-05 22:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-05 22:21 jeffxu [this message]
2022-08-05 22:21 ` [PATCH v2 1/5] mm/memfd: add F_SEAL_EXEC jeffxu
2022-08-05 22:21 ` [PATCH v2 2/5] mm/memfd: add MFD_NOEXEC flag to memfd_create jeffxu
2022-08-05 22:21 ` [PATCH v2 3/5] selftests/memfd: add tests for F_SEAL_EXEC jeffxu
2022-08-05 22:21 ` [PATCH v2 4/5] selftests/memfd: add tests for MFD_NOEXEC jeffxu
2022-08-05 22:21 ` [PATCH v2 5/5] sysctl: add support for mfd_noexec jeffxu
2022-08-13 18:35   ` kernel test robot
2022-08-13 19:06   ` kernel test robot
2022-08-08 17:46 ` [PATCH v2 0/5] mm/memfd: MFD_NOEXEC for memfd_create Kees Cook
2022-11-01 23:14   ` Jeff Xu
2022-11-02  2:45     ` Kees Cook
2022-11-02 17:18       ` Jeff Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220805222126.142525-1-jeffxu@google.com \
    --to=jeffxu@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dverkamp@chromium.org \
    --cc=hughd@google.com \
    --cc=jannh@google.com \
    --cc=jeffxu@chromium.org \
    --cc=jorgelo@chromium.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mnissler@chromium.org \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).