linux-mm.kvack.org archive mirror
 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>,
	"James Morris" <jmorris@namei.org>,
	"Stephen Smalley" <stephen.smalley.work@gmail.com>,
	"Hugh Dickins" <hughd@google.com>,
	"Jeff Vander Stoep" <jeffv@google.com>,
	"Nick Kralevich" <nnk@google.com>, "Jeff Xu" <jeffxu@google.com>,
	"Baolin Wang" <baolin.wang@linux.alibaba.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH] memfd,selinux: call security_inode_init_security_anon
Date: Mon, 15 Sep 2025 22:06:52 -0700 (PDT)	[thread overview]
Message-ID: <92255d5e-7e0a-6ca3-3169-114ae7f6247f@google.com> (raw)
In-Reply-To: <6afc91a9f5caef96b2ca335b6d143670@paul-moore.com>

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

On Wed, 3 Sep 2025, Paul Moore wrote:
> On Aug 25, 2025 "=?UTF-8?q?Thi=C3=A9baud=20Weksteen?=" <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>
> > Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > Tested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > ---
> > 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                   | 27 ++++++++++++++++++----
> >  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, 46 insertions(+), 6 deletions(-)
> > 
> > diff --git a/include/linux/memfd.h b/include/linux/memfd.h
> > index 6f606d9573c3..cc74de3dbcfe 100644
> > --- a/include/linux/memfd.h
> > +++ b/include/linux/memfd.h
> > @@ -4,6 +4,8 @@
> >  
> >  #include <linux/file.h>
> >  
> > +#define MEMFD_ANON_NAME "[memfd]"
> > +
> >  #ifdef CONFIG_MEMFD_CREATE
> >  extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg);
> >  struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx);
> > diff --git a/mm/memfd.c b/mm/memfd.c
> > index bbe679895ef6..63b439eb402a 100644
> > --- a/mm/memfd.c
> > +++ b/mm/memfd.c
> > @@ -433,6 +433,8 @@ static struct file *alloc_file(const char *name, unsigned int flags)
> >  {
> >  	unsigned int *file_seals;
> >  	struct file *file;
> > +	struct inode *inode;
> > +	int err = 0;
> >  
> >  	if (flags & MFD_HUGETLB) {
> >  		file = hugetlb_file_setup(name, 0, VM_NORESERVE,
> > @@ -444,12 +446,20 @@ static struct file *alloc_file(const char *name, unsigned int flags)
> >  	}
> >  	if (IS_ERR(file))
> >  		return file;
> > +
> > +	inode = file_inode(file);
> > +	err = security_inode_init_security_anon(inode,
> > +			&QSTR(MEMFD_ANON_NAME), NULL);
> > +	if (err) {
> > +		fput(file);
> > +		file = ERR_PTR(err);
> > +		return file;
> > +	}
> > +
> >  	file->f_mode |= FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE;
> >  	file->f_flags |= O_LARGEFILE;
> >  
> >  	if (flags & MFD_NOEXEC_SEAL) {
> > -		struct inode *inode = file_inode(file);
> > -
> >  		inode->i_mode &= ~0111;
> >  		file_seals = memfd_file_seals_ptr(file);
> >  		if (file_seals) {
> 
> Hugh, Baolin, and shmem/mm folks, are you okay with the changes above? If
> so it would be nice to get an ACK from one of you.

So far as I can tell, seems okay to me:
Acked-by: Hugh Dickins <hughd@google.com>

If I'd responded earlier (sorry), I would have asked for it just to use
&QSTR("[memfd]") directly in the call, rather than indirecting through
unnecessary #define MEMFD_ANON_NAME "[memfd]"; never mind, that's all.

Please do take this, along with the rest, through your security tree:
mm.git contains no conflicting change to mm/memfd.c at present.

Thanks,
Hugh

> 
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index c95a5874bf7d..429b2269b35a 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -93,6 +93,7 @@
> >  #include <linux/fanotify.h>
> >  #include <linux/io_uring/cmd.h>
> >  #include <uapi/linux/lsm.h>
> > +#include <linux/memfd.h>
> >  
> >  #include "avc.h"
> >  #include "objsec.h"
> > @@ -2366,9 +2367,12 @@ static int selinux_bprm_creds_for_exec(struct linux_binprm *bprm)
> >  	ad.type = LSM_AUDIT_DATA_FILE;
> >  	ad.u.file = bprm->file;
> >  
> > +	if (isec->sclass != SECCLASS_FILE && isec->sclass != SECCLASS_MEMFD_FILE)
> > +		return -EPERM;
> 
> In the interest of failing fast, this should probably be moved up in the
> function to just after where @isec is set.  There are also a number of
> checks that happen prior to this placement, but after the isec assignment.
> While I don't think any of those checks should be an issue, I'd rather
> not to have to worry about those and just fail the non-FILE/MEMFD_FILE
> case as soon as we can in selinux_bprm_creds_for_exec().
> 
> >  	if (new_tsec->sid == old_tsec->sid) {
> > -		rc = avc_has_perm(old_tsec->sid, isec->sid,
> > -				  SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, &ad);
> > +		rc = avc_has_perm(old_tsec->sid, isec->sid, isec->sclass,
> > +				  FILE__EXECUTE_NO_TRANS, &ad);
> >  		if (rc)
> >  			return rc;
> >  	} else {
> > @@ -2378,8 +2382,8 @@ static int selinux_bprm_creds_for_exec(struct linux_binprm *bprm)
> >  		if (rc)
> >  			return rc;
> >  
> > -		rc = avc_has_perm(new_tsec->sid, isec->sid,
> > -				  SECCLASS_FILE, FILE__ENTRYPOINT, &ad);
> > +		rc = avc_has_perm(new_tsec->sid, isec->sid, isec->sclass,
> > +				  FILE__ENTRYPOINT, &ad);
> >  		if (rc)
> >  			return rc;
> >  
> > @@ -2974,10 +2978,18 @@ static int selinux_inode_init_security_anon(struct inode *inode,
> >  	struct common_audit_data ad;
> >  	struct inode_security_struct *isec;
> >  	int rc;
> > +	bool is_memfd = false;
> >  
> >  	if (unlikely(!selinux_initialized()))
> >  		return 0;
> >  
> > +	if (name != NULL && name->name != NULL &&
> > +	    !strcmp(name->name, MEMFD_ANON_NAME)) {
> > +		if (!selinux_policycap_memfd_class())
> > +			return 0;
> > +		is_memfd = true;
> > +	}
> > +
> >  	isec = selinux_inode(inode);
> >  
> >  	/*
> > @@ -2996,6 +3008,13 @@ static int selinux_inode_init_security_anon(struct inode *inode,
> >  
> >  		isec->sclass = context_isec->sclass;
> >  		isec->sid = context_isec->sid;
> > +	} else if (is_memfd) {
> > +		isec->sclass = SECCLASS_MEMFD_FILE;
> > +		rc = security_transition_sid(
> > +			sid, sid,
> > +			isec->sclass, name, &isec->sid);
> > +		if (rc)
> > +			return rc;
> >  	} else {
> >  		isec->sclass = SECCLASS_ANON_INODE;
> >  		rc = security_transition_sid(
> 
> We're duplicating the security_transition_sid() call which seems less
> than ideal, how about something like this?
> 
>   if (context_inode) {
>     /* ... existing stuff ... */
>   } else {
>     if (is_memfd)
>       isec->sclass = SECCLASS_MEMFD_FILE;
>     else
>       isec->sclass = SECCLASS_ANON_INODE;
>     rc = security_transition_sid(...);
>     if (rc)
>       return rc;
>   }
> 
> --
> paul-moore.com

  reply	other threads:[~2025-09-16  5:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26  3:18 Thiébaud Weksteen
2025-08-27 13:23 ` Stephen Smalley
2025-08-28 13:29   ` Stephen Smalley
2025-08-29  3:17     ` Thiébaud Weksteen
2025-08-29 10:56     ` Paul Moore
2025-09-03 16:56   ` Stephen Smalley
2025-09-03 21:26 ` Paul Moore
2025-09-16  5:06   ` Hugh Dickins [this message]
2025-09-16 15:26     ` Paul Moore
2025-09-17  0:34       ` Thiébaud Weksteen
2025-09-17  1:08         ` Hugh Dickins

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=92255d5e-7e0a-6ca3-3169-114ae7f6247f@google.com \
    --to=hughd@google.com \
    --cc=baolin.wang@linux.alibaba.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