Re: [PATCH 0/8] userns: per-namespace capability bounding set and opt-in netns loopback

[Christian Brauner <brauner@kernel.org>]

On Wed, Oct 28, 2026 at 03:56:11PM -0700, Andy Lutomirski wrote:
> The whole unshare/clone flag situation is getting out of hand, IMO.
> And this new thing makes logical sense but is really about reducing
> exposure.
> 
> Perhaps we should instead have a small list associated with a userns
> (extensible in the future) of things that the ns's admin (i.e. whoever
> has CAP_SYS_ADMIN relative to the ns) may do.  That list could
> include:
> 
> - Create loopback with sensible defaults for ipv4 and/or ipv6 (i see
> no obvious reason to separate them)
> - Create tun/tap interfaces in that ns (and attach them, etc)
> 
> And add a very simple new API to do these things.  Actually, the

We've had this idea in the past and I think it is reasonable. I had
always thought that we should expose a system call to create empty
namespaces ot any type. Usually I'd be excited about that but I think
that point is a bit moot and I'd really like see whether we can turn
cells (or whatever other name) into a first class api.

The problem I have with the patchset as written is that adds a lot of
moving parts. And yes, I find the CLONE_* and UNSHARE_* flags plus
sysctl to be suboptimal as well.

So the TL;DR is that CAP_NET_ADMIN + userns =
CAP_NET_PRIVILEGE_ESCALATION 10+ years later. And this patchset wants to
put it back on a leash.

So why isn't an aggressively stupid solution to this problem to split a
new capability out of CAP_NET_ADMIN so it covers the absolute minimal
set of things that should be allowed instead of doing effectively the
same thing but split over multiple apis?

Anything that is reasonably advanced should not be the kernel's
responsibility to delegate. I really think the old privilege model where
the kernel grants control over a whole subsystem is inherently flawed
and is much better replaced if you have the means to let userspace
services grant and delegate resources.