[gnoack]

(Landlock reviewer here)

Namespaces can also be used for sandboxing, but they have a series of problems. Most importantly, they require more substantial changes to your program that wants to sandbox itself, and the program has to jump through a series of hoops to get everything into the right state. It is possible, but the resulting program environment is in the end more unusual and the mechanisms for enabling unprivileged namespaces are making it difficult to use it for smaller use cases. (It involves re-execution of the program that wants to sandbox itself, whereas with Landlock, a small program can just install a Landlock policy during an early startup phase and continue with that.)

Controlling the rules through a separate process is not currently possible, but it was proposed earlier this month on the kernel mailing lists:

https://lore.kernel.org/all/[e-mail]...

[bjackman]

I think in the upstream kernel LSMs are also still the only way to prevent a process from creating child namespaces where it has privileges?

E.g. if you can cat CAP_NET_ADMIN even within a restricted namespace, you have access to huge amounts of horrbly broken kernel code. It's easy (for people who know how to exploit kernel bugs) to escalate privileges from there.

Distros have their own fixes for this issue so namespaces definitely aren't useless in practice for sandboxing. But the basic mechanism just doesn't that well suited to it.

[anybody8824]

The user.max_user_namespaces sysctl itself is namespace aware and is used by bubblewrap's --disable-userns option.

But a prctl like NO_NEW_PRIVS would be better, since it could avoid an intermediary namespace that is needed for the namespace-aware sysctl.

[thiht]

Great answer, thanks!