On Wed, Jan 3, 2018 at 8:44 AM, Eric W. Biederman <ebied...@xmission.com> wrote: > Mahesh Bandewar <mah...@bandewar.net> writes: > >> From: Mahesh Bandewar <mahe...@google.com> >> >> 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 > [...]
