public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Paul Moore <paul@paul-moore.com>
Cc: "Thiébaud Weksteen" <tweek@google.com>,
	"Hugh Dickins" <hughd@google.com>,
	"James Morris" <jmorris@namei.org>,
	"Stephen Smalley" <stephen.smalley.work@gmail.com>,
	"Jeff Vander Stoep" <jeffv@google.com>,
	"Nick Kralevich" <nnk@google.com>, "Jeff Xu" <jeffxu@google.com>,
	"Baolin Wang" <baolin.wang@linux.alibaba.com>,
	"Isaac Manjarres" <isaacmanjarres@google.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v3] memfd,selinux: call security_inode_init_security_anon
Date: Sun, 21 Sep 2025 20:23:01 -0700 (PDT)	[thread overview]
Message-ID: <a3f1a528-c2dc-74a6-b671-d8b2ccf23183@google.com> (raw)
In-Reply-To: <CAHC9VhSbWJ-8tj5BxSTxznGO8zraKRSE31a+tqdfMHB53ef-MQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3224 bytes --]

On Sun, 21 Sep 2025, Paul Moore wrote:
> On Wed, Sep 17, 2025 at 10:04 PM Thiébaud Weksteen <tweek@google.com> wrote:
> >
> > Prior to this change, no security hooks were called at the creation of a
> > memfd file. It means that, for SELinux as an example, it will receive
> > the default type of the filesystem that backs the in-memory inode. In
> > most cases, that would be tmpfs, but if MFD_HUGETLB is passed, it will
> > be hugetlbfs. Both can be considered implementation details of memfd.
> >
> > It also means that it is not possible to differentiate between a file
> > coming from memfd_create and a file coming from a standard tmpfs mount
> > point.
> >
> > Additionally, no permission is validated at creation, which differs from
> > the similar memfd_secret syscall.
> >
> > Call security_inode_init_security_anon during creation. This ensures
> > that the file is setup similarly to other anonymous inodes. On SELinux,
> > it means that the file will receive the security context of its task.
> >
> > The ability to limit fexecve on memfd has been of interest to avoid
> > potential pitfalls where /proc/self/exe or similar would be executed
> > [1][2]. Reuse the "execute_no_trans" and "entrypoint" access vectors,
> > similarly to the file class. These access vectors may not make sense for
> > the existing "anon_inode" class. Therefore, define and assign a new
> > class "memfd_file" to support such access vectors.
> >
> > Guard these changes behind a new policy capability named "memfd_class".
> >
> > [1] https://crbug.com/1305267
> > [2] https://lore.kernel.org/lkml/20221215001205.51969-1-jeffxu@google.com/
> >
> > Signed-off-by: Thiébaud Weksteen <tweek@google.com>
> > ---
> > Changes since v2:
> > - Add WARN_ON when using unexpected class. Return -EACCES instead
> >   of -EPERM
> > - Remove extra new line
> > - Rebase on selinux/dev
> >
> > Changes since v1:
> > - Move test of class earlier in selinux_bprm_creds_for_exec
> > - Remove duplicate call to security_transition_sid
> >
> > Changes since RFC:
> > - Remove enum argument, simply compare the anon inode name
> > - Introduce a policy capability for compatility
> > - Add validation of class in selinux_bprm_creds_for_exec
> >  include/linux/memfd.h                      |  2 ++
> >  mm/memfd.c                                 | 14 ++++++++++--
> >  security/selinux/hooks.c                   | 26 +++++++++++++++++-----
> >  security/selinux/include/classmap.h        |  2 ++
> >  security/selinux/include/policycap.h       |  1 +
> >  security/selinux/include/policycap_names.h |  1 +
> >  security/selinux/include/security.h        |  5 +++++
> >  7 files changed, 44 insertions(+), 7 deletions(-)
> 
> Thanks Thiébaud, I'm going to merge this into selinux/dev-staging now
> with the plan to move it over to selinux/dev after the upcoming merge
> window closes.
> 
> Hugh, since the changes between this patch and the v2 you ACK'd are
> minimal and limited to the SELinux error handling code (see diff
> below), I'm going to carry over your ACK, but if you have any concerns
> or objections please let us know.

Sure, please do carry over my ACK - thanks.

Hugh

  reply	other threads:[~2025-09-22  3:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18  2:04 [PATCH v3] memfd,selinux: call security_inode_init_security_anon Thiébaud Weksteen
2025-09-18 13:21 ` Stephen Smalley
2025-09-21 18:31 ` Paul Moore
2025-09-22  3:23   ` Hugh Dickins [this message]
2025-09-22 13:12   ` Stephen Smalley
2025-09-22 19:30     ` Paul Moore
2025-10-13 16:11       ` Paul Moore
2025-10-13 22:19         ` Thiébaud Weksteen

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=a3f1a528-c2dc-74a6-b671-d8b2ccf23183@google.com \
    --to=hughd@google.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=isaacmanjarres@google.com \
    --cc=jeffv@google.com \
    --cc=jeffxu@google.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nnk@google.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=tweek@google.com \
    /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