Thread (2 messages) 2 messages, 2 authors, 2018-01-04

[PATCHv4 0/2] capability controlled user-namespaces

From: Mahesh Bandewar महेश बंडेवार <hidden>
Date: 2018-01-04 05:54:09
Also in: linux-api, lkml, netdev

On Wed, Jan 3, 2018 at 8:44 AM, Eric W. Biederman [off-list ref] wrote:
Mahesh Bandewar [off-list ref] writes:
quoted
From: Mahesh Bandewar <redacted>

TL;DR version
-------------
Creating a sandbox environment with namespaces is challenging
considering what these sandboxed processes can engage into. e.g.
CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc. just to name few.
Current form of user-namespaces, however, if changed a bit can allow
us to create a sandbox environment without locking down user-
namespaces.
In other conversations it appears it has been pointed out that user
namespaces are not necessarily safe under no_new_privs.  In theory
user namespaces should be safe but in practice not so much.

So let me ask.  Would your concerns be addressed if we simply made
creation and joining of user namespaces impossible in a no_new_privs
sandbox?
Isn't this another form of locking down user-ns similar to setting per
user-ns sysctl max_userns = 0?

Having said that, not allowing processes to create and/or attach
user-namespaces is going to be problematic and possibly a regression.
This (current) patchset doesn't do that. It allows users to create
user-ns's of any depth and number permitted by per-ns max_userns
sysctl. However one can decide what to take-off and what to leave in
terms of capabilities for the sandbox environment.

--mahesh..
Eric
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help