linux-kernel - Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

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]

Message-ID: <20160721145905.GC22680@htj.duckdns.org>
Date:	Thu, 21 Jul 2016 10:59:05 -0400
From:	Tejun Heo <tj@...nel.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Aleksa Sarai <asarai@...e.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Li Zefan <lizefan@...wei.com>,
	Johannes Weiner <hannes@...xchg.org>,
	"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
	Aditya Kali <adityakali@...gle.com>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	Christian Brauner <cbrauner@...e.de>, dev@...ncontainers.org
Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for
 direct descendants

Hello, James.

On Thu, Jul 21, 2016 at 07:51:49AM -0700, James Bottomley wrote:
> What I haven't really heard yet in the debate is the policy reason why
> an unprivileged user shouldn't set up their own cgroups as children of
> the current ones (inheriting the constraints).

It's not even about policies.  The interface just can't support
operations like this in a robust way.  We can try to hack enough holes
at it to make some scenarios work but it's all but guaranteed that
such approach is gonna cause painful long-term issues.

> I have heard
> 
>  * it would give power to move other tasks to more rigid constraints. 
>     To which the answer is only to allow movememnt of tasks in the
>    current cgroupns
>  * It violates the permissions delegation model.  This one doesn't
>    really make too much sense to me: in the same way the userns is root
>    in its own domain, cgroups ns is effective root for the restricted
>    cgroups (and only for processes within its ns).
> 
> Perhaps the question should be asked the other way around:  if we were
> explicitly delegating permission to every user in the system to set up
> their own sub cgroups, how would you advise it be done?

Coordinate in userspace.  Request whatever is managing the cgroup
hierarchy to set up delegation.  It's not like permission model is
fully contained in kernel on modern systems anyway.

Thanks.

-- 
tejun