On Thu, 17 Feb 2022 at 23:32, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Thu, Feb 17, 2022 at 9:24 AM Christian Göttsche > <cgzones@xxxxxxxxxxxxxx> wrote: > > On Thu, 27 Jan 2022 at 00:01, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > On Tue, Jan 25, 2022 at 9:33 AM Christian Göttsche > > > <cgzones@xxxxxxxxxxxxxx> wrote: > > > > > > > > Create a security context for the inodes created by memfd_secret(2) via > > > > the LSM hook inode_init_security_anon to allow a fine grained control. > > > > As secret memory areas can affect hibernation and have a global shared > > > > limit access control might be desirable. > > > > > > > > Signed-off-by: Christian Göttsche <cgzones@xxxxxxxxxxxxxx> > > > > --- > > > > An alternative way of checking memfd_secret(2) is to create a new LSM > > > > hook and e.g. for SELinux check via a new process class permission. > > > > --- > > > > mm/secretmem.c | 9 +++++++++ > > > > 1 file changed, 9 insertions(+) > > > > > > This seems reasonable to me, and I like the idea of labeling the anon > > > inode as opposed to creating a new set of LSM hooks. If we want to > > > apply access control policy to the memfd_secret() fds we are going to > > > need to attach some sort of LSM state to the inode, we might as well > > > use the mechanism we already have instead of inventing another one. > > > > Any further comments (on design or implementation)? > > > > Should I resend a non-rfc? > > I personally would really like to see a selinux-testsuite for this so > that we can verify it works not just now but in the future too. I > think having a test would also help demonstrate the usefulness of the > additional LSM controls. > Any comments (especially from the mm people)? Draft SELinux testsuite patch: https://github.com/SELinuxProject/selinux-testsuite/pull/80 > > One naming question: > > Should the anonymous inode class be named "[secretmem]", like > > "[userfaultfd]", or "[secret_mem]" similar to "[io_uring]"? > > The pr_fmt() string in mm/secretmem.c uses "secretmem" so I would > suggest sticking with "[secretmem]", although that is question best > answered by the secretmem maintainer. > > -- > paul-moore.com
