On Mon, Oct 2, 2017 at 11:12 AM, Mahesh Bandewar (महेश बंडेवार) <maheshb@xxxxxxxxxx> wrote: > On Mon, Oct 2, 2017 at 10:14 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: >> Quoting Mahesh Bandewar (mahesh@xxxxxxxxxxxx): >>> From: Mahesh Bandewar <maheshb@xxxxxxxxxx> >>> >>> [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.. > > [...] friendly ping. -- 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
