Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935173AbcLMSNm (ORCPT ); Tue, 13 Dec 2016 13:13:42 -0500 Received: from mail-oi0-f51.google.com ([209.85.218.51]:33624 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932886AbcLMSNh (ORCPT ); Tue, 13 Dec 2016 13:13:37 -0500 MIME-Version: 1.0 In-Reply-To: <4c60e1be-c00a-5f26-f5de-7d32b9cb0f62@schaufler-ca.com> References: <1481593143-18756-1-git-send-email-john.stultz@linaro.org> <221e80bd-3d99-6c35-dcd3-b2547f0abb11@schaufler-ca.com> <4c60e1be-c00a-5f26-f5de-7d32b9cb0f62@schaufler-ca.com> From: John Stultz Date: Tue, 13 Dec 2016 10:13:19 -0800 Message-ID: Subject: Re: [PATCH v5] cgroup: Add new capability to allow a process to migrate other tasks between cgroups To: Casey Schaufler Cc: Michael Kerrisk , lkml , Tejun Heo , 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" , Andy Lutomirski , 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: 2183 Lines: 40 On Tue, Dec 13, 2016 at 9:48 AM, Casey Schaufler wrote: > On 12/13/2016 9:24 AM, John Stultz wrote: >> On Tue, Dec 13, 2016 at 9:17 AM, Casey Schaufler wrote: >>> On 12/13/2016 8:49 AM, John Stultz wrote: >>>> On Tue, Dec 13, 2016 at 8:39 AM, Casey Schaufler wrote: >>>>> On 12/13/2016 1:47 AM, Michael Kerrisk (man-pages) wrote: >>>>>> How about CAP_CGROUP_CONTROL or some such, with the idea that this >>>>>> might be a capability that allows the holder to step outside usual >>>>>> cgroup rules? At the moment, that capability would allow only one such >>>>>> step, but maybe there would be others in the future. >>>>> I agree, but want to put it more strongly. The granularity of >>>>> capabilities can never be fine enough for some people, and this >>>>> is an example of a case where you're going a bit too far. If the >>>>> use case is Android as you say, you don't need this. As my friends >>>>> on the far side of the aisle would say, "just write SELinux policy" >>>>> to correctly control access as required. >>>> So.. The trouble is that while selinux is good for restricting >>>> permissions, the in-kernel permission checks here are already too >>>> restrictive. >>> Why did the original authors of cgroups make it that restrictive? >>> If there isn't a good reason, loosen it up. If there is a good >>> reason, then pay heed to it. >> That's what this patch is proposing. And I agree with Michael that the >> newly proposed cap was a bit to narrowly focused on my immediate use >> case, and broadening it to CGROUP_CONTROL is smart. Then that >> capability could be further restricted w/ selinux policy, as you >> suggest. > > Adding a new capability is unnecessary. The current use of CAP_SYS_NICE, > while arguably obscure, provides as much "security" as a new capability > does. While cgroups are a wonderful thing, they don't need a separate > capability. The trouble is that CAP_SYS_NICE or _RESOURCE (which was tried in an earlier version of this patch) aren't necessarily appropriate for non-android systems. See Andy's objection here: https://lkml.org/lkml/2016/11/8/946 thanks -john