linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Frederick Lawler <fred@cloudflare.com>,
	kpsingh@kernel.org, revest@chromium.org, jackmanb@chromium.org,
	ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
	john.fastabend@gmail.com, jmorris@namei.org, serge@hallyn.com,
	bpf@vger.kernel.org, linux-security-module@vger.kernel.org
Cc: brauner@kernel.org, paul@paul-moore.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, kernel-team@cloudflare.com,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 0/2] Introduce security_create_user_ns()
Date: Tue, 21 Jun 2022 17:19:15 -0700	[thread overview]
Message-ID: <ce1653b1-feb0-1a99-0e97-8dfb289eeb79@schaufler-ca.com> (raw)
In-Reply-To: <20220621233939.993579-1-fred@cloudflare.com>

On 6/21/2022 4:39 PM, Frederick Lawler wrote:
> While creating a LSM BPF MAC policy to block user namespace creation, we
> used the LSM cred_prepare hook because that is the closest hook to prevent
> a call to create_user_ns().
>
> The calls look something like this:
>
>      cred = prepare_creds()
>          security_prepare_creds()
>              call_int_hook(cred_prepare, ...
>      if (cred)
>          create_user_ns(cred)
>
> We noticed that error codes were not propagated from this hook and
> introduced a patch [1] to propagate those errors.
>
> The discussion notes that security_prepare_creds()
> is not appropriate for MAC policies, and instead the hook is
> meant for LSM authors to prepare credentials for mutation. [2]
>
> Ultimately, we concluded that a better course of action is to introduce
> a new security hook for LSM authors. [3]
>
> This patch set first introduces a new security_create_user_ns() function
> and create_user_ns LSM hook, then marks the hook as sleepable in BPF.

Why restrict this hook to user namespaces? It seems that an LSM that
chooses to preform controls on user namespaces may want to do so for
network namespaces as well. Also, the hook seems backwards. You should
decide if the creation of the namespace is allowed before you create it.
Passing the new namespace to a function that checks to see creating a
namespace is allowed doesn't make a lot off sense.

>
> Links:
> 1. https://lore.kernel.org/all/20220608150942.776446-1-fred@cloudflare.com/
> 2. https://lore.kernel.org/all/87y1xzyhub.fsf@email.froward.int.ebiederm.org/
> 3. https://lore.kernel.org/all/9fe9cd9f-1ded-a179-8ded-5fde8960a586@cloudflare.com/
>
> Frederick Lawler (2):
>    security, lsm: Introduce security_create_user_ns()
>    bpf-lsm: Make bpf_lsm_create_user_ns() sleepable
>
>   include/linux/lsm_hook_defs.h | 2 ++
>   include/linux/lsm_hooks.h     | 5 +++++
>   include/linux/security.h      | 8 ++++++++
>   kernel/bpf/bpf_lsm.c          | 1 +
>   kernel/user_namespace.c       | 5 +++++
>   security/security.c           | 6 ++++++
>   6 files changed, 27 insertions(+)
>
> --
> 2.30.2
>

  parent reply	other threads:[~2022-06-22  0:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-21 23:39 [PATCH 0/2] Introduce security_create_user_ns() Frederick Lawler
2022-06-21 23:39 ` [PATCH 1/2] security, lsm: " Frederick Lawler
2022-06-21 23:39 ` [PATCH 2/2] bpf-lsm: Make bpf_lsm_create_user_ns() sleepable Frederick Lawler
2022-06-22  0:19 ` Casey Schaufler [this message]
2022-06-22 14:24   ` [PATCH 0/2] Introduce security_create_user_ns() Frederick Lawler
2022-06-22 15:26     ` Casey Schaufler
2022-06-22 15:26     ` Casey Schaufler
2022-06-24  3:21     ` Paul Moore
2022-06-27 12:11       ` Christian Brauner
2022-06-27 15:51         ` Frederick Lawler
2022-06-27 15:56           ` Christian Brauner
2022-06-27 17:24             ` Casey Schaufler
2022-06-27 22:13           ` Paul Moore
2022-06-27 21:56         ` Paul Moore
2022-06-27 22:15           ` Daniel Borkmann
2022-06-27 22:27             ` KP Singh
2022-06-27 22:27             ` Paul Moore
2022-06-27 23:18               ` Casey Schaufler
2022-06-28 15:14                 ` Frederick Lawler
2022-06-28 16:02                   ` Casey Schaufler
2022-06-28 16:12                     ` KP Singh
2022-06-28 16:44                       ` Frederick Lawler
2022-06-28 15:11             ` Frederick Lawler
2022-06-28 15:13               ` Paul Moore
2022-06-30 18:28     ` Eric W. Biederman
2022-07-01  3:47       ` Frederick Lawler

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=ce1653b1-feb0-1a99-0e97-8dfb289eeb79@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=fred@cloudflare.com \
    --cc=jackmanb@chromium.org \
    --cc=jmorris@namei.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kernel-team@cloudflare.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=revest@chromium.org \
    --cc=serge@hallyn.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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;
as well as URLs for NNTP newsgroup(s).