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