From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934661AbcLMRtn (ORCPT ); Tue, 13 Dec 2016 12:49:43 -0500 Received: from nm14-vm1.bullet.mail.ne1.yahoo.com ([98.138.91.38]:57392 "EHLO nm14-vm1.bullet.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934439AbcLMRsw (ORCPT ); Tue, 13 Dec 2016 12:48:52 -0500 X-Yahoo-Newman-Id: 534163.75958.bm@omp1052.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xBOwmgcVM1l3NauyyYgcal1HZPZMNzCeF1H2fnKm3OQzjZg s1FEDeabkUSRJ282xtCMuee8iLnWFtQKQA2OhMJwJTFmREgvTCQjqSsbb1nj mH8w8fg1sAQaiiOOFZ29qx1M5JpjXbAjq_wqNRtZweScc2Ne2YTkLUWDNmp0 CFCwEw11EIUBImMEDvC08KZHkB3vnfPFO5hUGSDgkYpVx.du7.1r2MALUJxn H0ETqsP8WIVcEq1YEvRsoCQCNMMCRX0cQkXautjcectNWKbz06kzBuCG.RZq 5VTHn9_FQTJa1GwJESXwlBBvHOMTSSaSO3lPDi8Vp8mnN0YAAmHp1AhCj3YV aOlltZ9wlHI7VXXpXfcBQehVNrBZysirxenXProo4LI9zbjhs4ZbNR_u5fWL sVCjUvZJDxZl8Pfypc24pZ5nhHYoUSgFeE6uF0sZIO4emvde6UZAd88VuB6p l6ThwfQFBln4GtouvaskEUVrN15nGRrtstBxHCz56EjAhyfcoJ8VWQNr_7.m _7FT7eNG.oBQAi4h7MgkvxMxTYN4dvWfXYf52cO1K7.nsa.R7Fj6GCFvQUoT FHVhxu5OKUfRe X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [PATCH v5] cgroup: Add new capability to allow a process to migrate other tasks between cgroups To: John Stultz References: <1481593143-18756-1-git-send-email-john.stultz@linaro.org> <221e80bd-3d99-6c35-dcd3-b2547f0abb11@schaufler-ca.com> 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 From: Casey Schaufler Message-ID: <4c60e1be-c00a-5f26-f5de-7d32b9cb0f62@schaufler-ca.com> Date: Tue, 13 Dec 2016 09:48:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > thanks > -john >