Hi Abhinav Thanks for reaching out, it is great that you are interested in Landlock and IPE use cases for executable memfd.
Adding the latest discussion/status that I'm aware of, related to memfd, for reference - Thiébaud Weksteen (In CC) has patch [1] for a new selinux policy for memfd_create in [1] - Mickaël Salaün and I discussed the security hook to block executing memfd [2]. - Your recent patch in Landlock [3] [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/ [3] https://lore.kernel.org/all/[email protected]/ Thanks -Jeff -Jeff On Fri, Sep 19, 2025 at 11:10 PM Abhinav Saxena <[email protected]> wrote: > > Paul Moore <[email protected]> writes: > > > On Tue, Dec 13, 2022 at 10:00 AM Jeff Xu <[email protected]> wrote: > >> On Fri, Dec 9, 2022 at 10:29 AM Paul Moore <[email protected]> wrote: > >> > On Fri, Dec 9, 2022 at 11:05 AM <[email protected]> wrote: > >> > > > >> > > From: Jeff Xu <[email protected]> > >> > > > >> > > The new security_memfd_create allows lsm to check flags of > >> > > memfd_create. > >> > > > >> > > The security by default system (such as chromeos) can use this > >> > > to implement system wide lsm to allow only non-executable memfd > >> > > being created. > >> > > > >> > > Signed-off-by: Jeff Xu <[email protected]> > >> > > Reported-by: kernel test robot <[email protected]> > >> > > — > >> > > include/linux/lsm_hook_defs.h | 1 + > >> > > include/linux/lsm_hooks.h | 4 ++++ > >> > > include/linux/security.h | 6 ++++++ > >> > > mm/memfd.c | 5 +++++ > >> > > security/security.c | 5 +++++ > >> > > 5 files changed, 21 insertions(+) > >> > > >> > We typically require at least one in-tree LSM implementation to > >> > accompany a new LSM hook. Beyond simply providing proof that the hook > >> > has value, it helps provide a functional example both for reviewers as > >> > well as future LSM implementations. Also, while the BPF LSM is > >> > definitely “in-tree”, its nature is such that the actual > >> > implementation lives out-of-tree; something like SELinux, AppArmor, > >> > Smack, etc. are much more desirable from an in-tree example > >> > perspective. > >> > >> Thanks for the comments. > >> Would that be OK if I add a new LSM in the kernel to block executable > >> memfd creation ? > > > > If you would be proposing the LSM only to meet the requirement of > > providing an in-tree LSM example, no that would definitely *not* be > > okay. > > > > Proposing a new LSM involves documenting a meaningful security model, > > implementing it, developing tests, going through a (likely multi-step) > > review process, and finally accepting the long term maintenance > > responsibilities of this new LSM. If you are proposing a new LSM > > because you feel the current LSMs do not provide a security model > > which meets your needs, then yes, proposing a new LSM might be a good > > idea. However, if you are proposing a new LSM because you don’t want > > to learn how to add a new hook to an existing LSM, then I suspect you > > are misguided/misinformed with the amount of work involved in > > submitting a new LSM. > > > >> Alternatively, it might be possible to add this into SELinux or > >> landlock, it will be a larger change. > > > > It will be a much smaller change than submitting a new LSM, and it > > would have infinitely more value to the community than a throw-away > > LSM where the only use-case is getting your code merged upstream. > > Hi Paul/everyone! > > I am not sure what is the latest here. But it seems both landlock[1] and > IPE[2] have a use case for memfd_create(2) LSM hook. > > I would be happy to work on the use case for such a hook for landlock. > > CC’ing maintainers for both LSMs. > > -Abhinav > > [1] - > <https://lore.kernel.org/all/[email protected]/> > [2] - > <https://lore.kernel.org/linux-security-module/[email protected]/>
