User namespaces not used?

[xmikos]

Hello, your project looks great, but I have looked at your code and found this which concerns me:

// Cannot be used from golang as they can one be entered from
//  single threaded processes. See: setns(2)
//Namespace{Path: "ns/mnt", Type: syscall.CLONE_NEWNS},
//Namespace{Path: "ns/user", Type: syscall.CLONE_NEWUSER},

Am I right that you are not using user namespaces? Just because some limitation of Go language?This seems really insecure, unprivileged containers (user namespaces) seems like the only way how to make containers really secure (without it, root in container is like root on host system... at least this is what I have read about it, you can harden it with SELinux/AppArmor or other MAC, but it is still not that secure as user namespaces).

Are you planning to fix this? Or did I overlooked something?

[xSmurf]

Hello @xmikos,

Sorry for the late reply, as this was not an actual bug it was low on my priority list. This is however a question we get quite often.

First off the code and comment you are referring to is only related to opening of existing namespaces and not the actual sandbox/namespace handling. That comment refers to a property of these two namespaces which indeed cannot be entered from Golang as they must be entered from single threaded programs. However as you can see elsewhere in the project this can be worked around easily by using a C based constructor function (as used for oz-mount). For more information see man 2 setns:

A process may not be reassociated with a new mount namespace if it is multithreaded.

We are however indeed not using the user namespace. This is not an omission and not because of this Golang/Namespace limitation but because we do not believe the user namespace to actually provide any security benefits in a single user context. In fact it may actually lower security by giving extra capabilities to unprivileged users. Moreover preparations necessary to bring up a sandbox (such as network handling) would still require root or extra capabilities. This is often handled by giving the program root suid (such as ChromeOS' minijail) which we decided against in preference of the daemon/client model. Sandboxes in OZ do not allow root at all (to the exception of a debugging flag). And while it is true that root in a user namespace has slightly less capabilities than root outside of the sandbox, it is a false sense of security to believe that is not highly capable of being damaging outside of the sandbox.

This is all demonstrated by the fact that almost every single namespace escape security vulnerability so far has been related to the user namespace:

• Anatomy of a user namespaces vulnerability
• CVE-2015-1318 and CVE-2015-1862
• Linux Kernel User Namespace Local Security Bypass Vulnerability
• Docker 1.6.1 - Security Advisory
• Daily reminder that user namespaces are safe: You can now auto-load any kernel module: if (!fs && (request_module("%.*s", len, name) == 0))
• https://twitter.com/grsecurity/status/304572441999572992

To name only a few.

As such we do plan to add this "feature" to OZ.

Bests.

[xSmurf]

And again: http://seclists.org/fulldisclosure/2016/Jan/28

[xSmurf]

https://lwn.net/Articles/673613/

I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN over /any/ network namespace and to thus access the network configuration API to be a huge risk. For example, unprivileged users can program iptables. I'll eat my hat if there are no privilege escalations in there. - Andy Lutomirski

[xSmurf]

And again:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=378c6520e7d29280f400ef2ceaf155c86f05a71a

[xSmurf]

And again:

http://openwall.com/lists/oss-security/2017/03/29/2

From: Tyler Hicks <tyhicks@...onical.com>
Subject: CVE-2017-7184: kernel: Local privilege escalation in XFRM framework

A security issue was reported by ZDI, on behalf of Chaitin Security
Research Lab, against the Linux kernel in Ubuntu. It also affected the
upstream kernel.

Chaitin Security Research Lab discovered that xfrm_replay_verify_len(),
as called by xfrm_new_ae(), did not verify that the user-specified
replay_window was within the replay state buffer.

This allowed for out-of-bounds reads and writes of kernel memory.
Chaitin Security showed that this can lead to local privilege escalation
by using user namespaces in order to configure XFRM. XFRM configuration
requires CAP_NET_ADMIN so this issue is mitigated in kernels which do
not enable user namespaces by default.

[xSmurf]

DoS accessible via unpriv CAP_NET_RAW: http://seclists.org/oss-sec/2017/q1/697