On Thu, Feb 17, 2022 at 9:24 AM Christian Göttsche
[off-list ref] wrote:

On Thu, 27 Jan 2022 at 00:01, Paul Moore [off-list ref] wrote:

quoted

On Tue, Jan 25, 2022 at 9:33 AM Christian Göttsche
[off-list ref] wrote:

quoted

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 <redacted>
---
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.

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