20

I'm trying to figure out how to enable user namespaces capability in my kernel (I think CAP_SYS_USER_NS). I'm using Debian Stretch, kernel 4.6.0-1-amd64.

My assumption is there is a way to turn on user namespaces and recompile the kernel. After some hours searching, I can find a post of doing this in Ubuntu (https://blog.tutum.co/2013/12/14/enabling-the-user-namespace-in-ubuntu-13-10-saucy/) but not Debian (problem may be I'm on the wrong track and so my searches are off base).

My end game is to enable these in order to keep up with Docker and Google sandboxing which apparently require user namespaces to be enabled in the kernel (e.g., my Chrome containers no longer work).

28

On Debian userns is compiled-in but disabled by default. There's a Debian-specific patch to the kernel that adds this sysctl knob: kernel.unprivileged_userns_clone

So you have to add an new entry in /etc/sysctl.d and set it to 1

Manually that would be: echo 1 > /proc/sys/kernel/unprivileged_userns_clone (just to enable it until reboot)

for a permanent solution:

echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/00-local-userns.conf
service procps restart

It's possible there's an equivalent boot option parameter, I just don't know

  • 1
    This still works on Stretch, kernel 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux. – Reid Mar 8 '17 at 18:16
  • 1
    Is there a reason why it's disabled by default in Debian? – Melroy Mar 20 '18 at 13:56
  • 1
    Historically the security of user namespace was uncertain. eg: lwn.net/Articles/673597 . If a user, as root inside her own namespace can trick the kernel into allowing an operation on the real host, there's privilege escalation. Usual non-user namespaces require explicit root (so admin) permission and so run what the admin chose: that's a known risk. A later mechanism was added in vanilla kernel: user.max_user_namespaces . When set to 0 user namespaces are disabled. The Debian (actually from Ubuntu) patch is still around, even if probably obsolete. Maybe for compatibility reasons – A.B Mar 20 '18 at 14:30
  • 1
    Kernel 4.18.3 hasn't been released on Debian yet, so your kernel is not a Debian testing's kernel. You can ignore this parameter entirely (until you install an actual kernel from Debian). Also look at my previous comment about user.max_user_namespaces – A.B Aug 21 '18 at 23:57
  • 1
    This fix works for manjaro/arch with kernel 4.14 – stalet Sep 14 '18 at 9:10

protected by DavidPostill Jan 13 at 6:52

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.