Block access to user namespaces

[gerout7]

When running bubblewrap on systems with unprivileged user namespaces available, currently the runtime environment inside the bwrap sandbox does not block access to user namespaces, therefore allowing the sandboxed process to spawn new user namespaces. While this is useful in some cases like chrome-sandbox, which makes use of user namespaces for its own internal sandboxing features, most application have no use for it.

Since unprivileged user namspaces have a huge attack surface, shouldn't this feature generally be blocked by a sandbox?
While there could be an option to allow the use of unprivileged user namspaces within bubblewrap, I think it would be a good idea to block this feature by default for any process inside a bubblewrap jail.

While this could be archived by the end user by adding a seccomp filter for clone, unshare and setns in combination with the flags for user namespaces, I think this should be the default in bubblewrap.

[smcv]

unprivileged user namspaces have a huge attack surface

They do have a rather smaller attack surface inside bubblewrap, because NO_NEW_PRIVS should prevent any attack that relies on (ab)using a setuid executable.

While this could be archived by the end user by adding a seccomp filter for clone, unshare and setns in combination with the flags for user namespaces

bubblewrap isn't really designed to be used directly by end users. It provides enough namespace manipulation to be able to use namespace-based sandboxing on systems that otherwise don't allow it, like Debian 10 and RHEL/CentOS 7; it provides all the tools to make a sandbox, but doesn't directly implement any particular security model, and doesn't provide much in the way of convenience code to make things easier.

For user-friendly sandboxing with a ready-made security model, you'd be better off with Flatpak (which uses bubblewrap, and does use seccomp to prevent apps from entering further user namespaces) or something else that builds sandboxing around bubblewrap.

Because bubblewrap is setuid root on some systems, the bwrap executable needs to distrust its caller on those systems, and adding convenience code to it would expand bubblewrap's attack surface - for example, that's why it takes a precompiled seccomp eBPF program as an argument, rather than using libseccomp to compile user-specified rules or having shortcuts for commonly-used seccomp filters.

[smcv]

When running bubblewrap on systems with unprivileged user namespaces available, currently the runtime environment inside the bwrap sandbox does not block access to user namespaces, therefore allowing the sandboxed process to spawn new user namespaces.

#488 added a --disable-userns option to prevent access to user namespaces (without being syntactic sugar for seccomp - it sets limits instead). It also added an --assert-userns-disabled option, which tries to create a nested user namespace, and asserts that it can't - this can be used to ensure that a pre-existing user-specified userns passed to --userns or --userns2 was created with --disable-userns or similar.

While there could be an option to allow the use of unprivileged user namspaces within bubblewrap, I think it would be a good idea to block this feature by default for any process inside a bubblewrap jail.

That would be an incompatible change that breaks existing users of bubblewrap. As a concrete example, NixOS uses bubblewrap to enter a FHS-like environment for compatibility with third-party binaries like Steam, and relies on the ability to run bubblewrap (again) inside that environment, to implement the Steam container runtime. Making --disable-userns the default would break that overall system.

We take backwards-compatibility seriously, so disabling user namespace creation will not become the default. However, if we add a way to opt-in to groups of changes to defaults (#455), then it could become the default after opting in to compat level >= 1, or similar.