Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

[Aleksa Sarai]

Hi Tejun,

>> > Unfortunately, cgroup hierarchy isn't designed to support this sort
>> > of automatic delegation.  Unpriv processes would be able to escape
>> > constraints on v1 with some controllers and on v2 controllers have to
>> > be explicitly enabled by root for delegated scope to have access to
>> > them.
>>
>> Not necessarily.  We also talked about pinning the cgroup tree so that
>> once you enter the cgroup namespace, your current cgroup directory
>> becomes your root, meaning you can't cd back into the ancestors and
>> thus can't write their tasks file, meaning, I think, that it should be
>> impossible to escape ancestor constraints.
>
> I wish it were that clean.  Unfortunately, on v1, some controllers
> (memory and blkio depending on settings, netcls and netprio always)
> simply aren't properly hierarchical and if you have write perm to
> subdirectory you can escape the constraints of your ancestors.
> Whether you can cd back up or not doesn't matter at all, so we can't
> allow delegation by default.

I see two options here, which would allow us to have subtree
delegation without losing hierarchical structure:

1. Don't enable subtree delegation on v1 hierarchies. This would be
the simplest solution, and would cut out most people from using this
feature today -- but it would mean less work around trying to figure
out which hierarchies are safe to delegate (we make it explicit that
when you enable a cgroup on v2 that it must be safe to delegate by an
unprivileged user). We also get the benefit of having the more strict
cgroup.procs write rules.
2. Don't do subtree delegation on hierarchies that aren't
hierarchical. This would have to be done in collaboration with the
controllers (since cgroup core doesn't know which is hierarchical),
and would allow all users of cgroups today to get subtree delegation.

>> > Why does an unpriv NS need to have cgroup delegated to it without
>> > cooperation from cgroup manager?
>>
>> There's actually many answers to this.  The one I'm insterested in is
>> the ability for applications to make use of container features without
>> having to ask permission from some orchestration engine.  The problem
>
> What's "container features"?  Do you mean resource control by that?

Yes. Also the device cgroup. And ignoring the container usecase, it
would be useful to regular programs if they could use cgroup resource
accounting as part of their regular operation. Regular processes can
use rlimits -- why can't they use cgroups without needing cooperation
from an admin process (which makes for security and administration
issues).

>> most people are looking at is how do I prevent the cgroup manager from
>> running as root, because that's a security problem waiting to happen.
>
> It's distributing system wide resources so the top of the tree will
> always be owned by root and delegating subtrees is a fairly minimal
> operation.  I don't see how that would necessarily lead to security
> problems.

If I understand correctly, the security issues James is referring to
is that the cgroup manager could have a bug in it (and because the
cgroup interface is the filesystem, it would probably be some kind of
write-to-any-path bug). This is an intrinsic part of the model of "you
need to have cooperation with an admin process in order to use
resource limiting for your own processes".

-- 
Aleksa Sarai (cyphar)
www.cyphar.com