On 13/08/14 12:44 PM, Thomas Bächler wrote:
Am 13.08.2014 um 17:29 schrieb Damjan Georgievski:
On 13 August 2014 17:26, Damjan Georgievski <gdamjan@gmail.com> wrote:
yey thanks for CONFIG_USER_NS=y
ahh no, I'm stupid. Checked it on another machine and got excited before hand :/
anyway. is there a reason this is not enabled now? all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, Ubuntu and Debian (at least on the backported kernel)
I'd think about it, if the feature wasn't entirely useless. Despite the lack of official documentation, I found a document that described how it worked. After reading that document I concluded that the feature is a huge potential security risk with no actual benefit.
If you give me a valid use case for USER_NS, I might reconsider, but every use case I can imagine is crushed by the limitations of the implementation.
The use case is primarily allowing unprivileged containers, by making it possible to unshare namespaces, enter a chroot and do some mount operations as a regular user. The systemd user session provides the other half of the picture, which is using control groups as an unprivileged user. The secondary purpose is the quirky uid / gid mapping but I don't really understand the intended use case. It seems way too obscure to ever have it exposed in container implementations and you would need root to do anything interesting with it. It's completely broken from a security POV so enabling it without reverting the patch allowing unprivileged user namespaces isn't sane. The latest vulnerability was disclosed only yesterday: http://www.openwall.com/lists/oss-security/2014/08/12/6 The key patch for Fedora's kernel: http://pkgs.fedoraproject.org/cgit/kernel.git/tree/Revert-userns-Allow-unpri... The same -EPERM return for unprivileged users is also a non-optional part of the grsecurity patch set. AFAICT, it also prevents the class of mounts used in the latest CVE. I might just be misunderstanding how user namespaces are supposed to work.