User: Password:
|
|
Subscribe / Log in / New account

The past, present, and future of control groups

The past, present, and future of control groups

Posted Nov 22, 2013 10:50 UTC (Fri) by error27 (subscriber, #8346)
In reply to: The past, present, and future of control groups by Cyberax
Parent article: The past, present, and future of control groups

That is the attack.

People want to use control groups to divide resources between users.


(Log in to post comments)

The past, present, and future of control groups

Posted Nov 25, 2013 16:34 UTC (Mon) by nix (subscriber, #2304) [Link]

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.

The past, present, and future of control groups

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

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.

The past, present, and future of control groups

Posted Nov 27, 2013 22:54 UTC (Wed) by heijo (guest, #88363) [Link]

WTF?

Any intelligent person would design an hierarchical interface so that a node can only give to children what he could have been able to get himself.

BTW, *of course*, the user that is being contained by a cgroup must only be able to create and modify subcgroups and not the constraints of the cgroup itself.

Are the cgroup developers so incompetent to not realize this?

The past, present, and future of control groups

Posted Nov 30, 2013 20:48 UTC (Sat) by foom (subscriber, #14868) [Link]

It apparently wasn't actually designed to have edit permissions shared with non-privileged users, that was just an accidental side-effect of the API being filesystem directories with settable permissions.

Which is why the kernel devs are trying to take that ability away now.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds