32

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).

Improve this question
1

1 Answer 1

Reset to default
46

On Debian the ability to create or handle user namespaces from a non-privileged process (usually meaning non-root user) is disabled by default. There's a Debian-specific patch (from Ubuntu) to the kernel that adds the sysctl knob kernel.unprivileged_userns_clone (with a default value of 0 meaning disabled).

To enable it (until next reboot),

sudo sysctl -w kernel.unprivileged_userns_clone=1

For a permanent configuration, you can add a new entry in /etc/sysctl.d to enable the feature at boot:

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

This patch predates (by three years) the sysctl user.max_user_namespaces (initially userns.max_user_namespaces) which can be set to 0 to achieve the same result. It was probably kept around for (Debian) compatibility reasons: expecting the feature disabled by default.

From the initial commit message, it was created (in 2013) as a temporary measure when there were some doubts about the security implications related to using user namespaces:

add sysctl to disallow unprivileged CLONE_NEWUSER by default

This is a short-term patch. Unprivileged use of CLONE_NEWUSER is certainly an intended feature of user namespaces. However for at least saucy we want to make sure that, if any security issues are found, we have a fail-safe.

Improve this answer
12
  • 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, 2017 at 18:16
  • 3
    Is there a reason why it's disabled by default in Debian?
    – Melroy van den Berg
    Mar 20, 2018 at 13:56
  • 2
    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, 2018 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, 2018 at 23:57
  • 5
    Or simply : sudo sysctl -w kernel.unprivileged_userns_clone=1.
    – Skippy le Grand Gourou
    Apr 19, 2019 at 9:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .