public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Francis Laniel <flaniel@linux.microsoft.com>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-security-module@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>,
	Eric Biederman <ebiederm@xmission.com>,
	Serge Hallyn <serge@hallyn.com>, James Morris <jmorris@namei.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:BPF [MISC]" <bpf@vger.kernel.org>
Subject: Re: [RFC PATCH v4 0/2] Add capabilities file to securityfs
Date: Wed, 17 Aug 2022 13:53:21 +0200	[thread overview]
Message-ID: <4420381.LvFx2qVVIh@pwmachine> (raw)
In-Reply-To: <CAHC9VhTmgMfzc+QY8kr+BYQyd_5nEis0Y632w4S2_PGudTRT7g@mail.gmail.com>

Hi.


Le mardi 16 août 2022, 23:59:41 CEST Paul Moore a écrit :
> On Mon, Jul 25, 2022 at 8:42 AM Francis Laniel
> 
> <flaniel@linux.microsoft.com> wrote:
> > Hi.
> > 
> > First, I hope you are fine and the same for your relatives.
> 
> Hi Francis :)
> 
> > A solution to this problem could be to add a way for the userspace to ask
> > the kernel about the capabilities it offers.
> > So, in this series, I added a new file to securityfs:
> > /sys/kernel/security/capabilities.
> > The goal of this file is to be used by "container world" software to know
> > kernel capabilities at run time instead of compile time.
> 
> ...
> 
> > The kernel already exposes the last capability number under:
> > /proc/sys/kernel/cap_last_cap
> 
> I'm not clear on why this patchset is needed, why can't the
> application simply read from "cap_last_cap" to determine what
> capabilities the kernel supports?

When you capabilities with, for example, docker, you will fill capabilities 
like this:
docker run --rm --cap-add SYS_ADMIN debian:latest echo foo
As a consequence, the "echo foo" will be run with CAP_SYS_ADMIN set.

Sadly, each time a new capability is added to the kernel, it means "container 
stack" software should add a new string corresponding to the number of the 
capabilities [1].

The solution I propose would lead to "container stack" software to get rid of 
such an array and to test at runtime, if the name provided by user on the 
command line matches the name of a capability known by the kernel.
If it is the case, the number associated to the capability will be get by 
"container stack" code to be used as argument of capset() system call.

The advantage of this solution is that it would reduce the time taken between 
a new capability added to the kernel (e.g. CAP_BPF) and the time users can use 
it.
More generally, a solution to this problem would be a way for the kernel to 
expose the capabilities it knows.

Do not hesitate to ask for clarification if I was not clear.


Best regards.
---
[1] https://github.com/containerd/containerd/blob/
1a078e6893d07fec10a4940a5664fab21d6f7d1e/pkg/cap/cap_linux.go#L135



  reply	other threads:[~2022-08-17 11:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25 12:41 [RFC PATCH v4 0/2] Add capabilities file to securityfs Francis Laniel
2022-07-25 12:41 ` [RFC PATCH v4 1/2] capability: Add cap_string Francis Laniel
2022-07-25 12:41 ` [RFC PATCH v4 2/2] security/inode.c: Add capabilities file Francis Laniel
2022-08-16 21:59 ` [RFC PATCH v4 0/2] Add capabilities file to securityfs Paul Moore
2022-08-17 11:53   ` Francis Laniel [this message]
2022-08-17 14:52     ` Paul Moore
2022-08-17 15:49       ` Casey Schaufler
2022-08-17 16:10         ` Paul Moore
2022-08-17 16:19           ` Serge E. Hallyn
2022-08-17 16:22             ` Paul Moore
2022-08-17 16:49           ` Casey Schaufler
2022-08-17 17:19             ` Paul Moore

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=4420381.LvFx2qVVIh@pwmachine \
    --to=flaniel@linux.microsoft.com \
    --cc=bpf@vger.kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=ebiederm@xmission.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /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