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:09:10 -0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Tejun Heo <tj@...nel.org>
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

On Fri, 2016-05-20 at 09:03 -0700, Tejun Heo wrote:
> Hello, James.
> 
> On Fri, May 20, 2016 at 11:30:58AM -0400, James Bottomley wrote:
> > Given it's merge window time, I haven't yet had time to look at the
> > patch, but I can tell you why it (or something like it) is
> > necessary:
> > unprivileged containers need to be able to set up cgroups as well
> > as
> > namespaces, so we do need a way for the user ns owner to modify
> > cgroups
> > in their default configuration otherwise cgroups just won't fit
> > into
> > the unprivileged model.  Whether this should be through the cgroup
> > ns
> 
> That can be allowed by delegating a cgroup sub-hierarchy to the
> unpriviledged user.  Sub-cgroups created by that user will be owned 
> by that user.  IOW, if the owner of the cgroup hierarchy doesn't
> explicitly delegate the subtree, the unpriv user can't have the
> subtree.  This is true for regular use cases and shouldn't be
> different for namespaces.

The use case for unprivileged containers is that the end user should be
able to use them from the default configuration without and
administrator intervention (although there may be ways the admin can
prevent this if desired).  Your "deletage a cgroup sub-hierarchy"
requires admin intervention, so it's not yet a workflow that
unprivileged containers can use.

> 
> > is up for debate, as is how we should actually allow this to happen 
> > and what we should present to the user ns owner, but we do need a 
> > way to do this.
> > 
> > Delegation can't be through chmodding in this case because the user 
> > ns owner can't chmod something owned by init_user_ns root.
> 
> I still don't see why the existing mechanisms (including userns if
> delegation from inside a ns is necessary) aren't enough.  And even if
> we need something, I'd much prefer not to add a behavior which wildly
> deviates from the usual rules.

I think it's just different definitions.  If you take on our definition
of being able to set up a container without any admin intervention, do
you see our problem: we can't get the initial delegation of the
hierarchy.

James