Hacker News Reader

Comment by PyroLagus | Hacker News Reader

Apparently even user namespaces can't be trusted for secure isolation, so much so that Arch Linux even has them disabled by default[1]. That said, it's possible that security improved since then, and I don't know when the most recent user namespace vulnerability was found.

[1] https://lists.archlinux.org/pipermail/arch-general/2017-Febr...

View on HN

That mail is outdated. Arch, like some other distros such as debian, now applies a kernel patch that allows toggling userns support via kernel.unprivileged_userns_clone sysctl.

Oh, I'm aware that you can toggle it via sysctl, but it's still not on by default. That said, I can't find any user namespace CVE from 2019, only 2018, so maybe it's safe enough now. I guess "safe enough" is the keyword. If you really worry about the kernel's attack surface, you'll use a separation kernel, VMs, or separate machines altogether.

The issue is not that user namespaces cannot be used for secure isolation -- the problem is that it has been used for privilege escalation in the past. It definitely is more secure than it was 5+ years ago and there are ways of restricting its use on running systems through a couple of sysctls (in addition to the out-of-tree patch that Debian and Arch use).

But, in the case of running things in containers, you can stop exploits of user namespaces through seccomp filters that block unshare(CLONE_NEWUSER) -- Docker does this by default.

Reply on news.ycombinator.com