Date: Mon, 2 Oct 2017 11:12:09 -0700 From: Mahesh Bandewar (महेश बंडेवार) <maheshb@...gle.com> To: "Serge E. Hallyn" <serge@...lyn.com> Cc: Mahesh Bandewar <mahesh@...dewar.net>, 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>, "Eric W . Biederman" <ebiederm@...ssion.com>, Eric Dumazet <edumazet@...gle.com>, David Miller <davem@...emloft.net> Subject: Re: [PATCH 0/2] capability controlled user-namespaces On Mon, Oct 2, 2017 at 10:14 AM, Serge E. Hallyn <serge@...lyn.com> wrote: > Quoting Mahesh Bandewar (mahesh@...dewar.net): >> From: Mahesh Bandewar <maheshb@...gle.com> >> >> [Same as the previous RFC series sent on 9/21] >> >> 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. >> >> Detailed version >> ---------------- > > Hi, > > still struggling with how I feel about the idea in general. > > So is the intent mainly that if/when there comes an 0-day which allows > users with CAP_NET_ADMIN in any namespace to gain privilege on the host, > then this can be used as a stop-gap measure until there is a proper fix? > Thank for looking at this Serge. Yes, but at the same time it's not just limited to NET_ADMIN but could be any of the current capabilities. > Otherwise, do you have any guidance for how people should use this? > > IMO it should be heavily discouraged to use this tool as a regular > day to day configuration, as I'm not sure there is any "educated" > decision to be made, even by those who are in the know, about what > to put in this set. > I think that really depends on the environment. e.g. in certain sandboxes third-part / semi-trusted workload is executed where network resource is not used. In that environment I can easily take off NET_ADMIN and NET_RAW without affecting anything there. At the same time I wont have to worry about 0-day related to these two capabilities. I would say the Admins at these places are in the best place to decide what they can take-off safely and what they cannot. Even if they decide not to take-off anything, having a tool at hand to gain control is important when the next 0-day strikes us that can be exploited using any of the currently used capabilities. However, you are absolutely right in terms of using it as a stop-gap measure to protect environment until it's fixed and the capability in question can not be safely taken off permanently without hampering operations. thanks, --mahesh.. [...]
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.