BPF List
 help / color / mirror / Atom feed
From: Frederick Lawler <fred@cloudflare.com>
To: Casey Schaufler <casey@schaufler-ca.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
Subject: Re: [PATCH 0/2] Introduce security_create_user_ns()
Date: Wed, 22 Jun 2022 09:24:31 -0500	[thread overview]
Message-ID: <b72c889a-4a50-3330-baae-3bbf065e7187@cloudflare.com> (raw)
In-Reply-To: <ce1653b1-feb0-1a99-0e97-8dfb289eeb79@schaufler-ca.com>

Hi Casey,

On 6/21/22 7:19 PM, Casey Schaufler wrote:
> 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.
IIRC, CLONE_NEWUSER is the only namespace flag that does not require 
CAP_SYS_ADMIN. There is a security use case to prevent this namespace 
from being created within an unprivileged environment. I'm not opposed 
to a more generic hook, but I don't currently have a use case to block 
any others. We can also say the same is true for the other namespaces: 
add this generic security function to these too.

I'm curious what others think about this too.


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

I think having more context to a security hook is a good thing. I 
believe you brought up in the previous discussions that you'd like to 
use this hook for xattr purposes. Doesn't that require a namespace?

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


  reply	other threads:[~2022-06-22 14:24 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 ` [PATCH 0/2] Introduce security_create_user_ns() Casey Schaufler
2022-06-22 14:24   ` Frederick Lawler [this message]
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=b72c889a-4a50-3330-baae-3bbf065e7187@cloudflare.com \
    --to=fred@cloudflare.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=daniel@iogearbox.net \
    --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