[lkml]   [2014]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCHv1 7/8] cgroup: cgroup namespace setns support
On Mon, Oct 20, 2014 at 10:42 PM, Eric W. Biederman
<> wrote:
> Andy Lutomirski <> writes:
>> On Mon, Oct 20, 2014 at 9:49 PM, Eric W. Biederman
>> <> wrote:
>>> Andy Lutomirski <> 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.


 \ /
  Last update: 2014-10-21 08:01    [W:0.060 / U:7.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site