Date: Sat, 4 Nov 2017 18:53:46 -0500 From: "Serge E. Hallyn" <serge@...lyn.com> To: Mahesh Bandewar <mahesh@...dewar.net> Cc: LKML <linux-kernel@...r.kernel.org>, Netdev <netdev@...r.kernel.org>, Kernel-hardening <kernel-hardening@...ts.openwall.com>, Linux API <linux-api@...r.kernel.org>, Kees Cook <keescook@...omium.org>, Serge Hallyn <serge@...lyn.com>, "Eric W . Biederman" <ebiederm@...ssion.com>, Eric Dumazet <edumazet@...gle.com>, David Miller <davem@...emloft.net>, Mahesh Bandewar <maheshb@...gle.com> Subject: Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces Quoting Mahesh Bandewar (mahesh@...dewar.net): > Init-user-ns is always uncontrolled and a process that has SYS_ADMIN > that belongs to uncontrolled user-ns can create another (child) user- > namespace that is uncontrolled. Any other process (that either does > not have SYS_ADMIN or belongs to a controlled user-ns) can only > create a user-ns that is controlled. That's a huge change though. It means that any system that previously used unprivileged containers will need new privileged code (which always risks more privilege leaks through the new code) to re-enable what was possible without privilege before. That's a regression. I'm very much interested in what you want to do, But it seems like it would be worth starting with some automated code analysis that shows exactly what code becomes accessible to unprivileged users with user namespaces which was accessible to unprivileged users before. Then we can reason about classifying that code and perhaps limiting access to some of it.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.