linux-kernel - Re: [RFC PATCH] mm: create security context for memfd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhQXdNieG8_uWBfCCFSow6AVaxNBhB3GNU8ea1j5rjgZiA@mail.gmail.com>
Date:   Tue, 7 Jun 2022 16:10:28 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Christian Göttsche <cgzones@...glemail.com>
Cc:     SElinux list <selinux@...r.kernel.org>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        linux-security-module@...r.kernel.org,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] mm: create security context for memfd_secret inodes

On Mon, May 2, 2022 at 9:45 AM Christian Göttsche
<cgzones@...glemail.com> wrote:
> On Thu, 17 Feb 2022 at 23:32, Paul Moore <paul@...l-moore.com> wrote:
> > On Thu, Feb 17, 2022 at 9:24 AM Christian Göttsche
> > <cgzones@...glemail.com> wrote:
> > > On Thu, 27 Jan 2022 at 00:01, Paul Moore <paul@...l-moore.com> wrote:
> > > > On Tue, Jan 25, 2022 at 9:33 AM Christian Göttsche
> > > > <cgzones@...glemail.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@...glemail.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.

I think this patchset has been posted for long enough with no
comments, and no objections, that I can pull this into the
selinux/next tree.  However, I'll give it until the end of this week
just to give folks one last chance to comment.  If I don't hear any
objections by the end of day on Friday, June 10th I'll go ahead and
merge this.

-- 
paul-moore.com