Enable user namespaces in Debian kernel
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).
debian linux-kernel
add a comment |
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).
debian linux-kernel
add a comment |
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).
debian linux-kernel
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).
debian linux-kernel
debian linux-kernel
edited Oct 15 '17 at 6:23
A.B
1,3381511
1,3381511
asked Jun 28 '16 at 20:16
SenrabdetSenrabdet
91114
91114
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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, kernel4.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
Is there a reason why it's disabled by default in Debian?
– Melroy
Mar 20 '18 at 13:56
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
/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
Aug 21 '18 at 23:54
1
This fix works for manjaro/arch with kernel 4.14
– stalet
Sep 14 '18 at 9:10
|
show 3 more comments
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?
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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, kernel4.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
Is there a reason why it's disabled by default in Debian?
– Melroy
Mar 20 '18 at 13:56
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
/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
Aug 21 '18 at 23:54
1
This fix works for manjaro/arch with kernel 4.14
– stalet
Sep 14 '18 at 9:10
|
show 3 more comments
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, kernel4.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
Is there a reason why it's disabled by default in Debian?
– Melroy
Mar 20 '18 at 13:56
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
/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
Aug 21 '18 at 23:54
1
This fix works for manjaro/arch with kernel 4.14
– stalet
Sep 14 '18 at 9:10
|
show 3 more comments
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
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
edited Sep 10 '16 at 20:53
answered Sep 10 '16 at 13:57
A.BA.B
1,3381511
1,3381511
1
This still works on Stretch, kernel4.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
Is there a reason why it's disabled by default in Debian?
– Melroy
Mar 20 '18 at 13:56
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
/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
Aug 21 '18 at 23:54
1
This fix works for manjaro/arch with kernel 4.14
– stalet
Sep 14 '18 at 9:10
|
show 3 more comments
1
This still works on Stretch, kernel4.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
Is there a reason why it's disabled by default in Debian?
– Melroy
Mar 20 '18 at 13:56
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
/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
Aug 21 '18 at 23:54
1
This fix works for manjaro/arch with kernel 4.14
– stalet
Sep 14 '18 at 9:10
1
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
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
Is there a reason why it's disabled by default in Debian?
– Melroy
Mar 20 '18 at 13:56
Is there a reason why it's disabled by default in Debian?
– Melroy
Mar 20 '18 at 13:56
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
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
/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
Aug 21 '18 at 23:54
/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
Aug 21 '18 at 23:54
1
1
This fix works for manjaro/arch with kernel 4.14
– stalet
Sep 14 '18 at 9:10
This fix works for manjaro/arch with kernel 4.14
– stalet
Sep 14 '18 at 9:10
|
show 3 more comments
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?