2

I know unshare and nsenter are userland tools to work with linux namespaces. Since I, as much as possible, try to avoid working with root priveledges enabled, I often run into troubles with those tools unshare yielding me some "permissions denied".

I would firstly like to know how I can nevertheless make those tools usable for non-root users?

Also I would then secondly be told what risks or problems (in terms of security) I might phase making namespaces usable for non-root users?

My current partial knowledge related to this question, is that with the introduction of the user namespace kernel feature it would be possible for a non-root user to firstly create a new user namespace in which that user would be root and therefore to nestedly create the user namespaces subsequently from within that user namespace.

It would be helpful if an answer to this question would present and discuss other ways to enable the use of namespaces (i.e. network, ipc, mount, pid, ... etc.) for a non-root user, that is without using the user namespace (which currently might not be enable in all linux distribution). I imagine that a proxy setuid'ed program, might allow to use namespaces for non-roots while not being prone to leak priveledges? Maybe it is even something achievable in the famous sudo tools via editing /etc/sudoers ?

additionally background One reason I would like to be able to employ namespaces for a non-root user is that I could without risk of race-codition keepd track of child and descendant processes, given they'd be unruly and double fork or else setgpid() out of the process tree. This is to say, while I'm interested in the general case how to employ savely linux namespaces as a non-root user I would also appreciate any hint even if it only enabled to use the pid namespace.

humanityANDpeace
  • 14,392
  • A setuid program or one with CAP_SYS_ADMIN can manipulate namespaces, or you can sudo. You need to be careful around granting these privileges; eg if you allow anyone to; eg sudo nsenter could let me enter anyone's namespace and affect their processes. You may be better off writing your own routines that call setns() and manipulate namespaces directly. Then you can apply restrictions in your own code to ensure people can't do "bad" things. – Stephen Harris Aug 01 '16 at 12:42
  • @StephenHarris thanks for the sudo nsenter hint, which indeed is not without implications on securtiy. Yet with the exception of user namespaces it seemes to me any call of the unshare userspace tool rather limits than extends what can be done, is that your take too? – humanityANDpeace Aug 01 '16 at 12:48
  • sudo unshare /bin/sh - oops, I have full root access on the machine! – Stephen Harris Aug 01 '16 at 12:56
  • 1
    @StephenHarris but that would not result from unshare but from sudo and maybe a line like username ALL=(root) NOPASSWD: /usr/bin/unshare --pid --mount --mount-proc --fork su username might be the a way to not leak the sudo derived root priveledged. Actually it is exactly why it is such a pitty that unshare needs CAP_SYS_ADMIN for something that by itself (reduced the pid namespace) seems rather security improving, because it introduced sudo which is a good way to loose safety (as in you example) – humanityANDpeace Aug 01 '16 at 13:04
  • Good. Now you're going down a standard path. Instead of granting sudo to unshare you can write a wrapper script that can validate user input and allow limited types of commands and this script can call unshare. Now you can grant sudo to that script. It's easier for the end user (less to type), easier for you to control (stronger validation can be done inside the script), etc. This is a common paradigm for granting minimal privileges via sudo to programs that might be overly broad. – Stephen Harris Aug 01 '16 at 13:11

0 Answers0