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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 May 2016 12:53:26 -0400
From:	Tejun Heo <tj@...nel.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Aleksa Sarai <asarai@...e.de>, Li Zefan <lizefan@...wei.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Aleksa Sarai <cyphar@...har.com>, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, dev@...ncontainers.org
Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new
 cgroup namespaces

Hello,

On Fri, May 20, 2016 at 12:25:09PM -0400, James Bottomley wrote:
> OK, so is the only problem cleanup?  If so, what if I proposed that a

For generic cases, it's a much larger problem.  We'd have to change
delegation model completely so that delegations are allowed by
default, which btw can't be allowed on v1 hierarchies as some
controllers don't behave properly hierarchically in v1 and would allow
unpriv users to escape the constraints of its ancestors.

> cgroup directory could only be created by the owner of the userns
> (which would be any old unprivileged user) iff they create a cgroup ns
> and the cgroup ns would be responsible for removing it again, so the
> cgroup subdirectory would be tied to the cgroup namespace as its holder
> and we'd use release of the cgroup to remove all the directories?

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.  We can try to isolate these delegated subtrees and make them
work transparently, which rgroup tried to do, but that collides
directly with the vfs conventions (rgroups don't show up in cgroup
hierarchy at all so avoid this problem).

Why does an unpriv NS need to have cgroup delegated to it without
cooperation from cgroup manager?  If for resource control, I'm pretty
sure we don't want to allow that without explicit cooperation from the
enclosing scope.  Overall, it feels like this is trying to work around
an issue which should be solved from userland.

Thanks.

-- 
tejun