[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161206165519.GA17648@mtj.duckdns.org>
Date: Tue, 6 Dec 2016 11:55:19 -0500
From: Tejun Heo <tj@...nel.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: John Stultz <john.stultz@...aro.org>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Andy Lutomirski <luto@...nel.org>,
Mickaël Salaün <mic@...ikod.net>,
Daniel Mack <daniel@...que.org>,
"David S. Miller" <davem@...emloft.net>, kafai@...com,
Florian Westphal <fw@...len.de>,
Harald Hoyer <harald@...hat.com>,
Network Development <netdev@...r.kernel.org>,
Sargun Dhillon <sargun@...gun.me>,
Pablo Neira Ayuso <pablo@...filter.org>,
lkml <linux-kernel@...r.kernel.org>,
Li Zefan <lizefan@...wei.com>,
Jonathan Corbet <corbet@....net>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
Android Kernel Team <kernel-team@...roid.com>,
Rom Lemarchand <romlem@...roid.com>,
Colin Cross <ccross@...roid.com>,
Dmitry Shmidt <dimitrysh@...gle.com>,
Todd Kjos <tkjos@...gle.com>,
Christian Poetzsch <christian.potzsch@...tec.com>,
Amit Pundir <amit.pundir@...aro.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Kees Cook <keescook@...omium.org>,
"Serge E . Hallyn" <serge@...lyn.com>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a
process to migrate other tasks between cgroups
Hello,
On Mon, Dec 05, 2016 at 04:36:51PM -0800, Andy Lutomirski wrote:
> I really don't know. The cgroupfs interface is a bit unfortunate in
> that it doesn't really express the constraints. To safely migrate a
> task, ISTM you ought to have some form of privilege over the task
> *and* some form of privilege over the cgroup. cgroupfs only handles
> the latter.
>
> CAP_CGROUP_MIGRATE ought to be okay. Or maybe cgroupfs needs to gain
> a concept of "dangerous" cgroups and further restrict them and
> CAP_SYS_RESOURCE should be fine for non-dangerous cgroups? I think I
> favor the latter, but it might be nice to hear from Tejun first.
If we can't do CAP_SYS_RESOURCE due to overlaps, let's go with a
separate CAP. While for android and cgroup v1, it's nice to have a
finer grained CAP for security control, privilege isolation in cgroup
should also primarily done through hierarchical delegation. It
doesn't make sense to have another system in parallel.
We can't do it properly on v1 because some controllers aren't properly
hierarchical and delegation model isn't well defined. e.g. nothing
prevents a process from being pulled across different subtrees with
the same delegation, but v2 can do it properly. All that's necessary
is to make the CAP test OR'd to other perm checks instead of AND'ing
so that the CAP just allows overriding restrictions expressed through
delegation but it's normally possible to move processes around in
one's own delegated subtree.
Thanks.
--
tejun
Powered by blists - more mailing lists