[PATCH 0/2] Introduce security_create_user_ns()

[Frederick Lawler]

On 6/30/22 1:28 PM, Eric W. Biederman wrote:
> Frederick Lawler <fred at cloudflare.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?

No.

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

We agree that completely blocking this feature may disable effective 
sandboxing techniques, but uncontrolled user namespace creation 
increases the attack surface as well. There are known examples where 
creating a new namespace is the first step in a priv escalation attack.

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

Having a new security hook allows us to decide when unpriv user 
namespace creation is acceptable and unacceptable. Patching 
vulnerabilities takes time and effort amongst the community. We want to 
protect our systems so that we are not as impacted by the next 0-day 
disclosure. This in turn decreases our overall attack surface.

Security hooks are a good fit because they offer us flexibility to 
protect our systems how we see fit.

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