From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Subject: Re: [RFC 01/18] capabilities: track actually used capabilities
To: Andy Lutomirski <luto@amacapital.net>
References: <1465847065-3577-1-git-send-email-toiwoton@gmail.com>
 <1465847065-3577-2-git-send-email-toiwoton@gmail.com>
 <CALCETrWM7JupEWeyT5OUDozGG1-XMVpAX+Ah5QwiX+G0VyveDA@mail.gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>,
	Christoph Lameter <cl@linux.com>,
	"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	=?UTF-8?Q?Iago_L=c3=b3pez_Galeiras?= <iago@endocode.com>,
	Chris Metcalf <cmetcalf@ezchip.com>,
	Andy Lutomirski <luto@kernel.org>, Jann Horn <jann@thejh.net>,
	"open list:FILESYSTEMS (VFS and infrastructure)"
	<linux-fsdevel@vger.kernel.org>,
	"open list:CAPABILITIES" <linux-security-module@vger.kernel.org>
From: Topi Miettinen <toiwoton@gmail.com>
Message-ID: <6fd9daef-c9ed-9acb-53b8-438add7cdee8@gmail.com>
Date: Mon, 13 Jun 2016 20:45:59 +0000
MIME-Version: 1.0
In-Reply-To: <CALCETrWM7JupEWeyT5OUDozGG1-XMVpAX+Ah5QwiX+G0VyveDA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 06/13/16 20:32, Andy Lutomirski wrote:
> On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen <toiwoton@gmail.com> wrote:
>> Track what capabilities are actually used and present the current
>> situation in /proc/self/status.
> 
> What for?

Excerpt from the cover letter:

"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.

This patch series attempts to fix that by giving at least a nice starting
point from the actual maximum values. I looked where each limit is checked
and added a call to limit bump nearby.


Capabilities
[RFC 01/18] capabilities: track actually used capabilities

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."

Should I perhaps cite some of this in the commit?

>
> What is the intended behavior on fork()?  Whatever the intended
> behavior is, there should IMO be a selftest for it.
>
> --Andy
>

The capabilities could be tracked from three points of daemon
initialization sequence onwards:
fork()
setpcap()
exec()

fork() case would be logical as the /proc entry is per task. But if you
consider the tools to set the capabilities (for example systemd unit
files), there can be between fork() and exec() further preparations
which need more capabilities than the program itself needs.

setpcap() is probably the real point after which we are interested if
the capabilities are enough.

The amount of setup between setpcap() and exec() is probably very low.

-Topi