On Wed, Jan 3, 2018 at 8:44 AM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Mahesh Bandewar <mahesh@xxxxxxxxxxxx> writes: > >> From: Mahesh Bandewar <maheshb@xxxxxxxxxx> >> >> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html