Enable user namespaces in Debian kernel












18















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










share|improve this question





























    18















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










    share|improve this question



























      18












      18








      18


      10






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










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Oct 15 '17 at 6:23









      A.B

      1,3381511




      1,3381511










      asked Jun 28 '16 at 20:16









      SenrabdetSenrabdet

      91114




      91114






















          1 Answer
          1






          active

          oldest

          votes


















          26














          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






          share|improve this answer





















          • 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











          • 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










          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









          26














          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






          share|improve this answer





















          • 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











          • 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
















          26














          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






          share|improve this answer





















          • 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











          • 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














          26












          26








          26







          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






          share|improve this answer















          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







          share|improve this answer














          share|improve this answer



          share|improve this answer








          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, 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











          • 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





            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











          • 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





          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?



          Popular posts from this blog

          flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

          Mangá

           ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕