linux-kernel - Re: [PATCH v3 2/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]

Message-ID: <20160503155511.GA7110@mtj.duckdns.org>
Date:	Tue, 3 May 2016 11:55:11 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Aleksa Sarai <asarai@...e.de>
Cc:	Li Zefan <lizefan@...wei.com>,
	Johannes Weiner <hannes@...xchg.org>, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, dev@...ncontainers.org,
	Aleksa Sarai <cyphar@...har.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: [PATCH v3 2/2] cgroup: allow management of subtrees by new
 cgroup namespaces

Hello, Aleksa.

On Tue, May 03, 2016 at 11:52:22AM +1000, Aleksa Sarai wrote:
> However, I agree with James that this patchset isn't ideal (it was my first
> rough attempt). I think I'll get to work on properly virtualising
> /sys/fs/cgroup, which will allow for a new cgroup namespace to modify
> subtrees (but without allowing for cgroup escape) -- by pinning what pid
> namespace the cgroup was created under. We can use the same type of
> virtualization that /proc does (except instead of selectively showing the
> dentries, we selectively show different owners of the dentries).
> 
> Would that be acceptable?

I'm still not sold on the idea.  For better or worse, the permission
model is mostly based on vfs and I don't want to deviate too much as
that's likely to become confusing pretty quickly.  If a sub-hierarchy
is to be delegated, that's upto whomever is controlling cgroup
hierarchy in the sub-domain.  We can expand the perm checks to
consider user namespaces but I'd like to avoid going beyond that.

Thanks.

-- 
tejun