From: Topi Miettinen <toiwoton@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, luto@kernel.org, serge@hallyn.com,
keescook@chromium.org, Jonathan Corbet <corbet@lwn.net>,
Tejun Heo <tj@kernel.org>, Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
James Morris <james.l.morris@oracle.com>,
David Howells <dhowells@redhat.com>,
David Woodhouse <David.Woodhouse@intel.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Petr Mladek <pmladek@suse.com>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,
"open list:CAPABILITIES" <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH] capabilities: add capability cgroup controller
Date: Fri, 24 Jun 2016 01:14:46 +0000 [thread overview]
Message-ID: <6a129f00-dbef-9916-ffaa-792b6b413362@gmail.com> (raw)
In-Reply-To: <20160623164614.cc871a52402fca6179bef246@linux-foundation.org>
On 06/23/16 23:46, Andrew Morton wrote:
> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen <toiwoton@gmail.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
next prev parent reply other threads:[~2016-06-24 1:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-23 15:07 [PATCH] capabilities: add capability cgroup controller Topi Miettinen
2016-06-23 21:03 ` Kees Cook
2016-06-23 21:38 ` Tejun Heo
2016-06-24 0:22 ` Topi Miettinen
2016-06-24 15:48 ` Tejun Heo
2016-06-24 15:59 ` Serge E. Hallyn
2016-06-24 16:35 ` Tejun Heo
2016-06-24 16:59 ` Serge E. Hallyn
2016-06-24 17:21 ` Eric W. Biederman
2016-06-24 17:39 ` Serge E. Hallyn
2016-06-26 19:03 ` Topi Miettinen
2016-06-28 4:57 ` Eric W. Biederman
2016-07-02 11:20 ` Topi Miettinen
2016-06-24 17:24 ` Tejun Heo
2016-06-26 19:14 ` Topi Miettinen
2016-06-26 22:26 ` Tejun Heo
2016-06-27 14:54 ` Serge E. Hallyn
2016-06-27 19:10 ` Topi Miettinen
2016-06-27 19:17 ` Tejun Heo
2016-06-27 19:49 ` Serge E. Hallyn
2016-07-03 15:08 ` Topi Miettinen
2016-07-03 16:13 ` [PATCH] capabilities: audit capability use kbuild test robot
2016-07-07 9:16 ` [PATCH] capabilities: add capability cgroup controller Petr Mladek
2016-07-07 20:27 ` Topi Miettinen
2016-07-08 9:13 ` Petr Mladek
2016-07-09 16:38 ` Topi Miettinen
2016-07-10 9:04 ` Topi Miettinen
2016-06-23 23:46 ` Andrew Morton
2016-06-24 1:14 ` Topi Miettinen [this message]
2016-06-24 4:15 ` Andy Lutomirski
2016-06-25 18:00 ` Djalal Harouni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a129f00-dbef-9916-ffaa-792b6b413362@gmail.com \
--to=toiwoton@gmail.com \
--cc=David.Woodhouse@intel.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=james.l.morris@oracle.com \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=luto@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pmladek@suse.com \
--cc=serge.hallyn@canonical.com \
--cc=serge@hallyn.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).