I’m not proficient in how the Linux kernel works. I’ve observed that nested namespaces are not allowed in Flatpak. Are we unable to trust the kernel for nested namespace usage due to the attack surface? As far as I know, there’s no issue with nested seccomp and nested landlock. However, nested namespaces are seen as a security concern, and I can’t understand why due to my ignorance. I would appreciate it if you could enlighten me.
Back when namespaces were new, it was considered theoretically safe, but the attack surface was considered too large to expose to untrusted processes. Many distributions, like Debian, restricted namespaces to the root user (which is why bwrap exists). Those worries were proved sensible when an exploit was discovered that allowed escaping namespaces. Flatpak’s nested namespace restriction comes from that time.
Nowadaya, most distributions allow namespaces by unprivileged users, and most consider nested namespaces mostly safe.
Removing the restriction is apparently being considered. See https://lwn.net/Articles/1020571/
2 Likes
Having unprivileged user namespace available from a process’ point of view is a security risk. This way it can spawn a new user namespace and use a “fake” root user inside this namespace, which maps to a non-root user outside of this namespace.
Now you might ask, what is the problem, if this only maps to a non-root user outside the namespace. Well, it exposes much larger kernel attack surface inside this namespace, which usually would not be available to an unprivileged user and could be used for privilege escalation, if an attacker has an exploit for this additionally exposed attack surface.
This is the reason why the vast majority of sandboxes block namespace creation via seccomp filter. Even popular container solutions like Docker have a default seccomp filter which blocks namespace from a container point of view.
It also means that using nested sandboxes based on namespaces is not an optimal solution, since you can only block namespace creation within the most inner namespace.
Android, which is way more security focused than Linux desktop OSes, doesn’t even enable user namespaces in the kernel and uses other means for sandboxing (unix users, selinux and seccomp filters). Secureblue uses Selinux to block user namespaces globally and has domains available which allow unprivileged user namespaces for some applications which actually profit from user namespaces, like Trivalent.
Seccomp filters stack in a way, that you can only decrease attack surface, but not increase.
For anyone still following this discussion:
After looking at the discussion upstream at Flatpak, there is another reason why nested namespaces are banned in Flatpak: daemons like pipewire base their security precautions on the existence and contents of a file called .flatpak-info on the root folder from the perspective of the application connecting to a file. So if an application could create a new namespace where the .flatpak-info file was not present, it could trick other applications into thinking it was unsandboxed.