Why is it possible to create other namespaces without real root using user namespaces?

Question

When using the command unshare to create namespaces, if you are not the root in the host machine and creating any namespace but the user type, you will receive this error: Operation not permitted. Obviously, running as root will make it work.

So, if unshare -n (unshare the network namespace) gives this error, why unshare -Un (unshare the user and the network namespace) doesn't?

The first option I see but don't know if it is right is that all namespaces are, in fact, associated with a user namespace. If you don't have enough privileges, you can't associate new namespaces to it. But when you create a user namespace, you get the privileges, which becomes possible.

If the stated above is true, I could say that every process has a user namespace even if I never explicitly created it as a user? Would this work for other namespaces?

Edit: As pointed in the comments, unshare -Un could give the same error: operation not permitted. I am using an Ubuntu 20.04 for testing which comes with user namespaces enabled. I believe this is the difference.

Answer 1

Because why not?

Namespaces are, among other things, a sandboxing mechanism. They allow modifying certain settings inside an isolated domain without worrying whether they will affect the rest of the system.

Take mount namespaces as an example. Mounting file systems is normally a privileged operation: if you can mount arbitrary file systems, you can in particular mount a file system containing a set-user-id executable of your choosing and then execute it, thus performing a privilege escalation attack. However, launching a set-user-id executable inside a user namespace can only increase its privileges within that namespace: the root user ID inside the user namespace will be mapped to regular user ID outside the namespace, and process capabilities similarly apply only to resources subordinate to that namespace.

Without user namespaces, creating other kinds of namespaces might be exploited for privilege escalation in a similar way. But when ‘privilege’ is constrained to the user namespace, there is no reason any more not to allow it – and there are, in fact, some use cases for this. User namespaces don’t just constrain privileges, but also create the possibility of defining a privileged-unprivileged boundary within the namespace, preventing rogue processes from both escaping the sandbox entirely and taking over the sandbox itself.

The LWN article Namespaces in operation, part 6: more on user namespaces lists a number of possible applications for unprivileged creation of namespaces:

By isolating the effect of capabilities to namespaces, user namespaces thus deliver on the promise of safely allowing unprivileged users access to functionality that was formerly limited to the root user. This in turn creates interesting possibilities for new kinds of user-space applications. For example, it now becomes possible for unprivileged users to run Linux containers without root privileges, to construct Chrome-style sandboxes without the use of set-user-ID-root helpers, to implement fakeroot-type applications without employing dynamic-linking tricks, and to implement chroot()-based applications for process isolation. Barring kernel bugs, applications that employ user namespaces to access privileged kernel functionality are more secure than traditional applications based on set-user-ID-root: with a user-namespace-based approach, even if an applications is compromised, it does not have any privileges that can be used to do damage in the wider system.

That said, adding support for user namespaces has in itself introduced a number of security vulnerabilities to Linux (just one example), to the point where some distributions disable unprivileged creation of user namespaces by default.

If you’re looking for resources, the rest of the LWN series on namespaces covers the topic in quite a bit more depth.