linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: jeffxu@chromium.org
Cc: skhan@linuxfoundation.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 <lkp@intel.com>
Subject: Re: [PATCH v7 3/6] mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
Date: Wed, 14 Dec 2022 10:53:19 -0800	[thread overview]
Message-ID: <202212141053.DD016F79B@keescook> (raw)
In-Reply-To: <20221209160453.3246150-4-jeffxu@google.com>

On Fri, Dec 09, 2022 at 04:04:50PM +0000, jeffxu@chromium.org wrote:
> From: Jeff Xu <jeffxu@google.com>
> 
> The new MFD_NOEXEC_SEAL and MFD_EXEC flags allows application to
> set executable bit at creation time (memfd_create).
> 
> When MFD_NOEXEC_SEAL is set, memfd is created without executable bit
> (mode:0666), and sealed with F_SEAL_EXEC, so it can't be chmod to
> be executable (mode: 0777) after creation.
> 
> when MFD_EXEC flag is set, memfd is created with executable bit
> (mode:0777), this is the same as the old behavior of memfd_create.
> 
> The new pid namespaced sysctl vm.memfd_noexec has 3 values:
> 0: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
>         MFD_EXEC was set.
> 1: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL acts like
>         MFD_NOEXEC_SEAL was set.
> 2: memfd_create() without MFD_NOEXEC_SEAL will be rejected.
> 
> The sysctl allows finer control of memfd_create for old-software
> that doesn't set the executable bit, for example, a container with
> vm.memfd_noexec=1 means the old-software will create non-executable
> memfd by default. Also, the value of memfd_noexec is passed to child
> namespace at creation time. For example, if the init namespace has
> vm.memfd_noexec=2, all its children namespaces will be created with 2.
> 
> Signed-off-by: Jeff Xu <jeffxu@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

  reply	other threads:[~2022-12-14 18:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09 16:04 [PATCH v7 0/6] mm/memfd: introduce MFD_NOEXEC_SEAL and MFD_EXEC jeffxu
2022-12-09 16:04 ` [PATCH v7 1/6] mm/memfd: add F_SEAL_EXEC jeffxu
2022-12-09 16:04 ` [PATCH v7 2/6] selftests/memfd: add tests for F_SEAL_EXEC jeffxu
2022-12-14 18:52   ` Kees Cook
2022-12-09 16:04 ` [PATCH v7 3/6] mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC jeffxu
2022-12-14 18:53   ` Kees Cook [this message]
2022-12-16 18:39   ` SeongJae Park
2022-12-16 19:03     ` Jeff Xu
2022-12-16 19:21       ` Andrew Morton
2022-12-16 19:31         ` SeongJae Park
2022-12-09 16:04 ` [PATCH v7 4/6] mm/memfd: Add write seals when apply SEAL_EXEC to executable memfd jeffxu
2022-12-09 16:04 ` [PATCH v7 5/6] selftests/memfd: add tests for MFD_NOEXEC_SEAL MFD_EXEC jeffxu
2022-12-09 16:04 ` [PATCH v7 6/6] mm/memfd: security hook for memfd_create jeffxu
2022-12-09 17:02   ` Casey Schaufler
2022-12-09 18:29   ` Paul Moore
2022-12-13 15:00     ` Jeff Xu
2022-12-13 15:37       ` Casey Schaufler
2022-12-13 19:22       ` Paul Moore
2022-12-13 23:05         ` Jeff Xu
2025-09-20  5:54         ` Abhinav Saxena
2025-09-20 18:58           ` Jeff Xu
2022-12-09 18:15 ` [PATCH v7 0/6] mm/memfd: introduce MFD_NOEXEC_SEAL and MFD_EXEC Paul Moore
2022-12-14 18:54 ` Kees Cook
2022-12-14 23:32   ` Jeff Xu
2022-12-15  0:08     ` Kees Cook
2022-12-15 16:55       ` 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=202212141053.DD016F79B@keescook \
    --to=keescook@chromium.org \
    --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=jeffxu@google.com \
    --cc=jorgelo@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lkp@intel.com \
    --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).