Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 6, 2013 18:29 UTC (Fri) by jubal (subscriber, #67202)
Parent article: Another daemon for managing control groups

BTW, I think it's worthy to paste here the Tejun Heo's comment from Lennart's exquisite google+ complaint note:

Ooh, some clarifications.

* Yes, I think cgroup should be managed by some entity which is trusted and privileged. There are two big reasons for this.

One is the fact that the whole thing is neither designed or implemented for delegation to untrusted domain. As I've now mentioned multiple times, security is mostly about logistics and details and implementing something with huge and complex interface surface without meticulously auditing every detail and expecting it to be secure is outright stupid. I can assure everyone that delegating cgroup to !priv has always been insecure and AFAICS it will continue to be - you can create vmalloc allocations of unlimited size, you can put processes into undefined hung state which will also drag your debugger into the same state if it tries to attach to it, and so on. Just imagine implementing this same feature with system calls and how much effort we'd have to be putting in in secure design and implementation. cgroup has not done any of it. Expecting it to be securely delegatable is fairy-tale naive.

The second is that delegating to !priv users often leads to each binary growing awareness of cgroup interface and manipulating it directly. This immediately promotes cgroup interface to the status of system calls, which is completely messed up. It becomes a side channel to breach the kernel API design and review process. I don't even understand how something like this has ever been allowed to happen but this has served as an active shortcut for both kernel and userland devs and is disastrous for both in the long term.

I don't know how designed this delegation to untrusted domain “feature” is. I suspect it came about as an accident just because the interface was filesystem based. Anyways, kernel devs have been working assuming the interface is a privileged admin thing and some userland has been happily delegating them out to untrusted domains.

* Serge seems to be mostly on the same page. I don't think there were any fundamental misunderstandings. It was just me being stupid about how chown was being used in its scheme which seems fine now.

* Google folks can speak for themselves but I asked around at the recent conferences and they don't seem to have any fundamental disagreements at this point. All the contention points were quite minor, or they at least seemed that way to me.

Hope this clears up at least some of the misunderstandings. Thanks.

to post comments

Another daemon for managing control groups

Posted Dec 7, 2013 8:53 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

And let me post my rants from the comments:

I've been using delegation to !priv users with the current cgroup design just fine. It works as expected - I simply give permissions to a cgroup subtree to a user and they can do whatever they want.

I have heard the claim that cgroup delegation is uber-insecure and will eat your pets for lunch about 100^500 times by now. But somehow people always omit the exact details of the horrible gaping security holes. Except for the brain-damaged "starve your siblings" scenario and non-hierarchical cgroups (which are a mis-feature in themselves).

Let's see your technical objections:

1) "Putting processes into an undefined state and fouling up the debugger". Boohoo. So a !priv user can mess with their debugger. Horrible. And totally unprecedented, since ptrace is a nice rock-solid interface that always works flawlessly.

2) Unlimited vmalloc - totally a kernel issue that MUST be fixed anyway.

And your non-technical objections: cgroup ABI must be treated as an ABI. That ALREADY is true, systemd is NOT going to be the single user of the cgroups ABI and so it must be stable.

Next, let's see the requirements for the central cgroups daemon. It must support delegation to other users. At minimum, to support containers running old versions of systemd or other cgroup users.

How can this be done? I envision a way to delegate a subtree of the whole cgroups tree and allow the delegated software to be limited to using it.

So you need to have a way to isolate a part of DBUS tree and make sure only authorized users can access it.

Then there's a question of security - how do I audit cgroups delegation tree? Is there an audit API?

Can I use my favorite AppArmor (systemd is going to fully support AppArmor, right?) policies to make sure that only one process in my cgroups+namespaces based container is allowed to tinker with cgroups? How do I make sure that my browser can't ask for a delegated cgroups tree using this nice systemd-based DBUS interface?

Basically, ALL these issues are solved nicely with the classic Linux filesystem-based interfaces. And trying to solve them another way would just generate a solution isomorphic to a filesystem tree. Except it'll be stupid and buggy.