From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751846AbcFYSAk (ORCPT ); Sat, 25 Jun 2016 14:00:40 -0400 Received: from mail-qk0-f194.google.com ([209.85.220.194]:35647 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751355AbcFYSAi (ORCPT ); Sat, 25 Jun 2016 14:00:38 -0400 MIME-Version: 1.0 In-Reply-To: References: <1466694434-1420-1-git-send-email-toiwoton@gmail.com> <20160623164614.cc871a52402fca6179bef246@linux-foundation.org> <6a129f00-dbef-9916-ffaa-792b6b413362@gmail.com> From: Djalal Harouni Date: Sat, 25 Jun 2016 20:00:36 +0200 Message-ID: Subject: Re: [PATCH] capabilities: add capability cgroup controller To: Andy Lutomirski Cc: Topi Miettinen , Andrew Morton , "linux-kernel@vger.kernel.org" , Andrew Lutomirski , "Serge E. Hallyn" , Kees Cook , Jonathan Corbet , Tejun Heo , Li Zefan , Johannes Weiner , Serge Hallyn , James Morris , David Howells , David Woodhouse , Ard Biesheuvel , "Paul E. McKenney" , Petr Mladek , "open list:DOCUMENTATION" , "open list:CONTROL GROUP (CGROUP)" , "open list:CAPABILITIES" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 24, 2016 at 6:15 AM, Andy Lutomirski wrote: > On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote: >> On 06/23/16 23:46, Andrew Morton wrote: >>> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote: >>> >>>> There are many basic ways to control processes, including capabilities, >>>> cgroups and resource limits. However, there are far fewer ways to find >>>> out useful values for the limits, except blind trial and error. >>>> >>>> Currently, there is no way to know which capabilities are actually used. >>>> Even the source code is only implicit, in-depth knowledge of each >>>> capability must be used when analyzing a program to judge which >>>> capabilities the program will exercise. >>>> >>>> Add a new cgroup controller for monitoring of capabilities >>>> in the cgroup. >>> >>> I'm having trouble understanding how valuable this feature is to our >>> users, and that's a rather important thing! >>> >>> Perhaps it would help if you were to explain your motivation: >>> particular use cases which benefited from this, for example. >>> >> >> It's easy to control with for example systemd or many other tools, which >> capabilities a service should have at the start. But how should a system >> administrator, application developer or distro maintaner ever determine >> a suitable value for this? Currently the only way seems to be to become >> an expert on capabilities, make an educated guess how the set of >> programs in question happen to work in this context and especially how >> they could exercise the capabilites in all possible use cases. Even >> then, the outcome is to just try something to see if that happens to >> work. Reading the source code (if available) does not help very much, >> because the use of capabilities is anything but explicit there. >> >> This is way too difficult, there must be some easier way. The >> information which capabilities actually were used in a trial run gives a >> much better starting point. The users can just use the list of used >> capabilities with configuring the service or when developing or >> maintaining the application. Of course, even that could still fail >> eventually, but then you simply copy the new value of used capabilities >> to the configuration, whereas currently you have to reconsider your >> understanding of the capabilities and the programs in light of the >> failure, which by itself might give no new useful information. >> >> One way to solve this for good would be to make the use of capabilities >> explicit in the ABI. For example, there could be a system call >> dac_override() which would be the only possible way ever to use the >> capability CAP_DAC_OVERRIDE and so forth. Then reading source code, >> tracing and many other approaches would be useful. But the OS with that >> kind of ABI (not Linux) would not be Unix-like at all for any >> (potentially) capability using programs, like find(1) or cat(1). > > The problem is that most of the capabilities are so powerful on their > own that limiting services to just a few may be all but useless. May be there is some gain _if_ the resources that a process interact with _can_ also be made invisible with namespaces. > --Andy > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- tixxdz http://opendz.org