[veonik]

Yikes... are other popular distros shipping with unprivileged user namespaces enabled by default?

[marcthe12]

Most, I think Debian has patch to be disabled at runtime via sysctl. The reason is that most containers or sandboxing techniques are root only unless you mix it with user namescapes. So most container or sandbox software use suid(firejail) , root daemon(docker) or user namescapes (podman and flatpak). Looking at the cves, user namespaces is probably the safer option

[galangalalgol]

That is part of enabling rootless containers on rhel or similar.

[waynesonfire]

should have re-written it in rust.

[yjftsjthsd-h]

Rewritten what? The container runtime will need the same access regardless of what it's written in, and rewriting all of Linux (the kernel) would be... ambitious, although it is adopting rust incrementally.

[scns]

The good old Strangler Pattern.

https://martinfowler.com/bliki/StranglerFigApplication.html

[galangalalgol]

Some of the issue though is that a monolithic kernel provides more access than necessary to many things. When they made the locks granular, those might be reasonable boundaries for permissions? At this point I'd rather figure out how to make windows drivers work in redox or something crazy like that.

[failsecure]

Yes and this decision haunts distros like Ubuntu over and over again. There's no easy win though.

[touisteur]

Do you need a user namespace? I'd expect a network namespace to be enough. Am I missing something?

Edit: should've read better, this seems to need CLONE_NEWUSER.

[jwilk]

You need CAP_SYS_ADMIN to create a new network namespace.