Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753793AbcLFQza (ORCPT ); Tue, 6 Dec 2016 11:55:30 -0500 Received: from mail-qk0-f196.google.com ([209.85.220.196]:35219 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753186AbcLFQzW (ORCPT ); Tue, 6 Dec 2016 11:55:22 -0500 Date: Tue, 6 Dec 2016 11:55:19 -0500 From: Tejun Heo To: Andy Lutomirski Cc: John Stultz , Alexei Starovoitov , Andy Lutomirski , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , 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 Subject: Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups Message-ID: <20161206165519.GA17648@mtj.duckdns.org> References: <1478647728-30357-1-git-send-email-john.stultz@linaro.org> <20161109000342.GA42532@ast-mbp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1502 Lines: 33 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