Enable user namespaces in Debian kernel

28

15

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

Senrabdet

Posted 2016-06-28T20:16:33.493

Reputation: 281

1

See also the same question: https://unix.stackexchange.com/q/303213/4319

– imz -- Ivan Zakharyaschev – 2019-10-23T22:10:23.587

Answers

39

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

A.B

Posted 2016-06-28T20:16:33.493

Reputation: 2 008

1This 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 – 2017-03-08T18:16:57.850

1Is there a reason why it's disabled by default in Debian? – Melroy – 2018-03-20T13:56:36.717

2

Historically the security of user namespace was uncertain. eg: https://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 – 2018-03-20T14:30:10.043

/proc/sys/kernel/unprivileged_userns_clone doesn't exist on my Debian testing/buster install. What kernel config does this require? I'm on kernel 4.18.3. – nnyby – 2018-08-21T23:54:05.470

1Kernel 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 – 2018-08-21T23:57:25.007

I'm compiling my own kernel - that's why it's newer than Debian's release. Also, I found the kernel config option, it's called CONFIG_USER_NS. – nnyby – 2018-08-22T00:28:31.683

1This fix works for manjaro/arch with kernel 4.14 – stalet – 2018-09-14T09:10:24.043

1

Indeed the same patch is applied by Manjaro ( https://gitlab.manjaro.org/packages/core/linux414/blob/master/0001-add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by.patch )

– A.B – 2018-09-14T11:46:20.677

3Or simply : sudo sysctl -w kernel.unprivileged_userns_clone=1. – Skippy le Grand Gourou – 2019-04-19T09:47:46.403

@SkippyleGrandGourou nice but where do you add this to as a default startup parameter. I'm running MX Linux. maybe I'd better check their docs – Slabo – 2019-08-09T23:00:30.230

@Slabo well... it's written in my answer ("permanent solution"). SkippyleGrandGourou wrote the equivalent command involved when the configuration file is read, which is better than echo (avoids shell problems with sudo) – A.B – 2019-08-10T08:26:33.903

1

As for ALT Linux distros (there, it's different from Debian), see https://unix.stackexchange.com/a/303214/4319 ; it's: sysctl -w kernel.userns_restrict=0

– imz -- Ivan Zakharyaschev – 2019-10-23T22:12:17.133