On 12/13/2022 7:00 AM, Jeff Xu wrote: > On Fri, Dec 9, 2022 at 10:29 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >> On Fri, Dec 9, 2022 at 11:05 AM <jeffxu@xxxxxxxxxxxx> wrote: >>> From: Jeff Xu <jeffxu@xxxxxxxxxx> >>> >>> 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 <jeffxu@xxxxxxxxxx> >>> Reported-by: kernel test robot <lkp@xxxxxxxxx> >>> --- >>> 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 ? > Alternatively, it might be possible to add this into SELinux or > landlock, it will be a larger change. I expect you'll get other opinions, but I'd be happy with a small LSM that does sophisticated memory fd controls. I also expect that the SELinux crew would like to see a hook included there. > > Thanks > > Jeff > > >> -- >> paul-moore.com
