Re: [PATCH 0/2] Introduce security_create_user_ns()

[Frederick Lawler]

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@xxxxxxxxxxxxxx/
> > 2. 
> > https://lore.kernel.org/all/87y1xzyhub.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ 
> >
> > 3. 
> > https://lore.kernel.org/all/9fe9cd9f-1ded-a179-8ded-5fde8960a586@xxxxxxxxxxxxxx/ 
> >
> >
> > 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