Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753520AbcLFRBl (ORCPT ); Tue, 6 Dec 2016 12:01:41 -0500 Received: from mail-ua0-f176.google.com ([209.85.217.176]:33093 "EHLO mail-ua0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752353AbcLFRBj (ORCPT ); Tue, 6 Dec 2016 12:01:39 -0500 MIME-Version: 1.0 In-Reply-To: <20161206165519.GA17648@mtj.duckdns.org> References: <1478647728-30357-1-git-send-email-john.stultz@linaro.org> <20161109000342.GA42532@ast-mbp.thefacebook.com> <20161206165519.GA17648@mtj.duckdns.org> From: Andy Lutomirski Date: Tue, 6 Dec 2016 09:01:17 -0800 Message-ID: Subject: Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups To: Tejun Heo Cc: John Stultz , Alexei Starovoitov , Andy Lutomirski , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Daniel Mack , "David S. Miller" , kafai@fb.com, Florian Westphal , Harald Hoyer , Network Development , Sargun Dhillon , Pablo Neira Ayuso , lkml , Li Zefan , Jonathan Corbet , "open list:CONTROL GROUP (CGROUP)" , Android Kernel Team , Rom Lemarchand , Colin Cross , Dmitry Shmidt , Todd Kjos , Christian Poetzsch , Amit Pundir , Dmitry Torokhov , Kees Cook , "Serge E . Hallyn" , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2006 Lines: 38 On Tue, Dec 6, 2016 at 8:55 AM, Tejun Heo wrote: > 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. How would one be granted the right to move processes around in one's own subtree? Are you imagining that, if you're in /a/b and you want to move a process that's currently in /a/b/c to /a/b/d then you're allowed to because the target process is in your tree? If so, I doubt this has the security properties you want -- namely, if you can cooperate with anyone in /, even if they're unprivileged, you can break it.