Message-ID: <87v8singyt.fsf@email.froward.int.ebiederm.org>
Date:   Thu, 30 Jun 2022 13:28:42 -0500
From:   "Eric W. Biederman" <ebiederm@...ssion.com>
To:     Frederick Lawler <fred@...udflare.com>
Cc:     Casey Schaufler <casey@...aufler-ca.com>, kpsingh@...nel.org,
        revest@...omium.org, jackmanb@...omium.org, ast@...nel.org,
        daniel@...earbox.net, andrii@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, john.fastabend@...il.com,
        jmorris@...ei.org, serge@...lyn.com, bpf@...r.kernel.org,
        linux-security-module@...r.kernel.org, brauner@...nel.org,
        paul@...l-moore.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: [PATCH 0/2] Introduce security_create_user_ns()

Frederick Lawler <fred@...udflare.com> writes:

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

There is also a very strong security use case for not putting security
checks in the creation of the user namespace.

In particular there are all kinds of kernel features that are useful for
building sandboxes namespaces, chroot, etc, that previous to user
namespaces were not possible to make available to unprivileged users
because they could confuse suid-root executables.  With user namespaces
the concern about confusing suid-root executable goes away.

The only justification I have ever heard for restricting the user
namespace is because it indirectly allows for greater kernel attack
surface.

Do you have a case for restricting the user namespace other than the
kernel is buggy and the user namespace makes the kernel bugs easier
to access?

How does increasing the attack surface of the kernel make the situation
that the kernel is buggy and the attack surface is too big better?

Perhaps it is explained somewhere down-thread and I just have not caught
up yet, but so far I have not see a description of why it makes sense
for a security module to restrict the kernel here.

Eric

p.s.  I am little disappointed that I was not copied on this thread
given that it is my code you are messing with, and I was in an earlier
version of this thread.

Powered by blists - more mailing lists