lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEjxPJ7Y_gkPN4-iS5Q8h16oE8Y1=vD=i=Yu4qQwHKyS97+4Wg@mail.gmail.com>
Date: Wed, 3 Sep 2025 12:56:06 -0400
From: Stephen Smalley <stephen.smalley.work@...il.com>
To: Thiébaud Weksteen <tweek@...gle.com>
Cc: Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, 
	Hugh Dickins <hughd@...gle.com>, Jeff Vander Stoep <jeffv@...gle.com>, Nick Kralevich <nnk@...gle.com>, 
	Jeff Xu <jeffxu@...gle.com>, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, selinux@...r.kernel.org, 
	linux-mm@...ck.org
Subject: Re: [PATCH] memfd,selinux: call security_inode_init_security_anon

On Wed, Aug 27, 2025 at 9:23 AM Stephen Smalley
<stephen.smalley.work@...il.com> wrote:
>
> On Mon, Aug 25, 2025 at 11:18 PM Thiébaud Weksteen <tweek@...gle.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@...gle.com>
>
> This looks good to me, but do you have a test for it, preferably via
> patch for the selinux-testsuite?
> See https://github.com/SELinuxProject/selinux-testsuite/commit/023b79b8319e5fe222fb5af892c579593e1cbc50
> for an example.
>
> Otherwise, you can add my:
> Acked-by: Stephen Smalley <stephen.smalley.work@...il.com>

And now having run the tests posted in:
    https://lore.kernel.org/selinux/20250902055401.618729-1-tweek@google.com/
you can also add my:
Tested-by: Stephen Smalley <stephen.smalley.work@...il.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ