[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a129f00-dbef-9916-ffaa-792b6b413362@gmail.com>
Date: Fri, 24 Jun 2016 01:14:46 +0000
From: Topi Miettinen <toiwoton@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, luto@...nel.org, serge@...lyn.com,
keescook@...omium.org, Jonathan Corbet <corbet@....net>,
Tejun Heo <tj@...nel.org>, Li Zefan <lizefan@...wei.com>,
Johannes Weiner <hannes@...xchg.org>,
Serge Hallyn <serge.hallyn@...onical.com>,
James Morris <james.l.morris@...cle.com>,
David Howells <dhowells@...hat.com>,
David Woodhouse <David.Woodhouse@...el.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Petr Mladek <pmladek@...e.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
"open list:CAPABILITIES" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] capabilities: add capability cgroup controller
On 06/23/16 23:46, Andrew Morton wrote:
> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen <toiwoton@...il.com> 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).
-Topi
Powered by blists - more mailing lists