linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: "Christian Göttsche" <cgzones@googlemail.com>
Cc: selinux@vger.kernel.org, James Morris <jmorris@namei.org>,
	 "Serge E. Hallyn" <serge@hallyn.com>,
	linux-security-module@vger.kernel.org,
	 Stephen Smalley <stephen.smalley.work@gmail.com>,
	Eric Paris <eparis@parisplace.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm: create security context for memfd_secret inodes
Date: Wed, 26 Jan 2022 18:01:30 -0500	[thread overview]
Message-ID: <CAHC9VhSdGeZ9x-0Hvk9mE=YMXbpk-tC5Ek+uGFGq5U+51qjChw@mail.gmail.com> (raw)
In-Reply-To: <20220125143304.34628-1-cgzones@googlemail.com>

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.

> diff --git a/mm/secretmem.c b/mm/secretmem.c
> index 22b310adb53d..b61cd2f661bc 100644
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c
> @@ -164,11 +164,20 @@ static struct file *secretmem_file_create(unsigned long flags)
>  {
>         struct file *file = ERR_PTR(-ENOMEM);
>         struct inode *inode;
> +       const char *anon_name = "[secretmem]";
> +       const struct qstr qname = QSTR_INIT(anon_name, strlen(anon_name));
> +       int err;
>
>         inode = alloc_anon_inode(secretmem_mnt->mnt_sb);
>         if (IS_ERR(inode))
>                 return ERR_CAST(inode);
>
> +       err = security_inode_init_security_anon(inode, &qname, NULL);
> +       if (err) {
> +               file = ERR_PTR(err);
> +               goto err_free_inode;
> +       }
> +
>         file = alloc_file_pseudo(inode, secretmem_mnt, "secretmem",
>                                  O_RDWR, &secretmem_fops);
>         if (IS_ERR(file))
> --
> 2.34.1

-- 
paul-moore.com


  reply	other threads:[~2022-01-26 23:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 14:33 Christian Göttsche
2022-01-26 23:01 ` Paul Moore [this message]
2022-02-17 14:24   ` Christian Göttsche
2022-02-17 22:32     ` Paul Moore
2022-05-02 13:45       ` Christian Göttsche
2022-06-07 20:10         ` Paul Moore
2022-06-13 18:17           ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHC9VhSdGeZ9x-0Hvk9mE=YMXbpk-tC5Ek+uGFGq5U+51qjChw@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgzones@googlemail.com \
    --cc=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=stephen.smalley.work@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox