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] [day] [month] [year] [list]

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

Hello, Aleksa.

On Sat, May 28, 2016 at 03:12:16PM +1000, Aleksa Sarai wrote:
> 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.

Regardless of the above two, the proposed solution is too hacky and
doesn't fit with the overall design.  At the moment, I'm not sure the
problem is worth solving.

> >> > 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).

The current VFS based interface simply isn't conducive to such usage.
e.g. What if someone else relocates the process while it was trying to
access its interface files?  What if the permission or ownership
changes beneath the process.

> 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".

Sure, that's the inherent characteristic of the interface that cgroup
ended up with.  I'm not a big fan of it either but 1. it still is a
workable model 2. adding mismatching hacks on top is highly likely to
lead to interface disaster in the long term.

Thanks.

-- 
tejun