On Mon, Oct 20, 2014 at 10:42 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > >> On Mon, Oct 20, 2014 at 9:49 PM, Eric W. Biederman >> <ebiederm@xxxxxxxxxxxx> wrote: >>> Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: >>>> Possible solution: >>>> >>>> Ditch the pinning. That is, if you're outside a cgroupns (or you have >>>> a non-ns-confined cgroupfs mounted), then you can move a task in a >>>> cgroupns outside of its root cgroup. If you do this, then the task >>>> thinks its cgroup is something like "../foo" or "../../foo". >>> >>> Of the possible solutions that seems attractive to me, simply because >>> we sometimes want to allow clever things to occur. >>> >>> Does anyone know of a reason (beyond pretty printing) why we need >>> cgroupns to restrict the subset of cgroups processes can be in? >>> >>> I would expect permissions on the cgroup directories themselves, and >>> limited visiblilty would be (in general) to achieve the desired >>> visiblity. >> >> This makes the security impact of cgroupns very easy to understand, >> right? Because there really won't be any -- cgroupns only affects >> reads from /proc and what cgroupfs shows, but it doesn't change any >> actual cgroups, nor does it affect any cgroup *changes*. > > It seems like what we have described is chcgrouproot aka chroot for > cgroups. At which point I think there are potentially similar security > issues as for chroot. Can we confuse a setuid root process if we make > it's cgroup names look different. > > Of course the confusing root concern is handled by the usual namespace > security checks that are already present. I think that the chroot issues are mostly in two categories: setuid confusion (not an issue here as you described) and chroot escapes. cgroupns escapes aren't a big deal, I think -- admins should deny the confined task the right to write to cgroupfs outside its hierarchy, by setting cgroupfs permissions appropriately and/or avoiding mounting cgroupfs outside the hierarchy. > > I do wonder if we think of this as chcgrouproot if there is a simpler > implementation. Could be. I'll defer to Aditya for that one. > >>>> While we're at it, consider making setns for a cgroupns *not* change >>>> the caller's cgroup. Is there any reason it really needs to? >>> >>> setns doesn't but nsenter is going to need to change the cgroup >>> if the pinning requirement is kept. nsenenter is going to want to >>> change the cgroup if the pinning requirement is dropped. >>> >> >> It seems easy enough for nsenter to change the cgroup all by itself. > > Again. I don't think anyone has suggested or implemented anything > different. The current patchset seems to punt on this decision by just failing the setns call if the caller is outside the cgroup in question. --Andy _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers