lkml.org 
[lkml]   [2022]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH] mm: create security context for memfd_secret inodes
On Thu, 17 Feb 2022 at 23:32, Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Feb 17, 2022 at 9:24 AM Christian Göttsche
> <cgzones@googlemail.com> wrote:
> > On Thu, 27 Jan 2022 at 00:01, Paul Moore <paul@paul-moore.com> wrote:
> > > On Tue, Jan 25, 2022 at 9:33 AM Christian Göttsche
> > > <cgzones@googlemail.com> 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@googlemail.com>
> > > > ---
> > > > 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

\
 
 \ /
  Last update: 2022-05-02 15:46    [W:0.057 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site