The past, present, and future of control groups [LWN.net]

The past, present, and future of control groups

Posted Nov 25, 2013 16:34 UTC (Mon) by nix (subscriber, #2304)
In reply to: The past, present, and future of control groups by error27
Parent article: The past, present, and future of control groups

Well, obviously if you delegate control of a subtree to a user, that user has to be trusted to make changes to that subtree. That's why you did it! If the user then proceeds to make changes, those changes are not an 'attack': they are the intended use of the API.

You might as well say that kill(2) is insecure because it allows you to send signals to processes that they might not be ready for.

to post comments

The past, present, and future of control groups

Posted Nov 25, 2013 16:50 UTC (Mon) by corbet (editor, #1) [Link] (1 responses)

The point is that said user should not be able to affect processes outside of the subtree, and things don't work that way now. There are also, apparently, denial-of-service issues and such — nothing keeps that user from creating an arbitrary number of control groups and running the kernel out of memory, for example. Or so I understand it, but I'm often confused.

The past, present, and future of control groups

Posted Nov 26, 2013 1:59 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

The only example of this I've seen so far is the ability to steal resources from sibling cgroups. But that's easily fixed by including an intermediate group to insulate delegated subtree from its siblings.

I.e.:

root -- cgroup1 (1000)
     -- cgroup2 (1000)

In this case if I delegate the 'cgroup2' to a malicious user, then they can set the resource share to 1000000 and starve the 'cgroup1'.

But that can be easily fixed:

root -- cgroup1 (1000)
     -- delegate2 (1000) - cgroup2

In this case I can safely delegate "cgroup2" to an untrusted user, they won't be able to starve other cgroups because its resource allocation is limited by the intermediate 'delegate2' group.

Now, some cgroups don't properly support hierarchy so it's not possible to create such hierarchy but these cgroups are being fixed right now.

The past, present, and future of control groups

Posted Nov 26, 2013 4:05 UTC (Tue) by raven667 (subscriber, #5198) [Link]

If kill was suid root then maybe it would be a more apt comparison.