linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Francis Laniel <flaniel@linux.microsoft.com>
To: linux-kernel@vger.kernel.org, Casey Schaufler <casey@schaufler-ca.com>
Cc: Serge Hallyn <serge@hallyn.com>,
	linux-security-module@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [RFC PATCH v1 0/2] Add capabilities file to sysfs
Date: Tue, 28 Dec 2021 14:34:24 +0100	[thread overview]
Message-ID: <2639798.l7ez0hRiAL@machine> (raw)
In-Reply-To: <7d1d7682-dd19-1b8a-ee5a-50fe6479589b@schaufler-ca.com>

Hi.

Le lundi 27 décembre 2021, 23:22:41 CET Casey Schaufler a écrit :
> On 12/27/2021 12:54 PM, Francis Laniel wrote:
> > Hi.
> > 
> > 
> > First, I hope you are fine and the same for your relatives.
> > 
> > Capabilities are used to check if a thread has the right to perform a
> > given
> > action [1].
> > For example, a thread with CAP_BPF set can use the bpf() syscall.
> > 
> > Capabilities are used in the container world.
> > In terms of code, several projects related to container maintain code
> > where the capabilities are written alike include/uapi/linux/capability.h
> > [2][3][4][5]. For these projects, their codebase should be updated when a
> > new capability is added to the kernel.
> > Some other projects rely on <sys/capability.h> [6].
> > In this case, this header file should reflect the capabilities offered by
> > the kernel.
> > 
> > So, in this series, I added a new file to sysfs: /sys/kernel/capabilities.
> 
> This should be /sys/kernel/security/capabilities.

I began to write code to move this under /sys/kernel/security/capabilities but 
I realized this directory is linked to CONFIG_SECURITYFS.
This option is not required to be able to run container [1].
Also, kernel/capability.c is always compiled, so I think it is better if this 
file (i.e. the one which prints capabilities to user) does not depend on any 
CONFIG_.

What do you think of it? Does this sound acceptable for you?

> > 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 underlying kernel attribute is read-only and its content is the
> > capability number associated with the capability name:
> > root@vm-amd64:~# cat /sys/kernel/capabilities
> > 0       CAP_CHOWN
> > 1       CAP_DAC_OVERRIDE
> > ...
> > 39      CAP_BPF
> > 
> > The kernel already exposes the last capability number under:
> > /proc/sys/kernel/cap_last_cap
> > So, I think there should not be any issue exposing all the capabilities it
> > offers.
> > If there is any, please share it as I do not want to introduce issue with
> > this series.
> > 
> > Also, if you see any way to improve this series please share it as it
> > would
> > increase this contribution quality.
> > 
> > Francis Laniel (2):
> >    capability: Add cap_strings.
> >    kernel/ksysfs.c: Add capabilities attribute.
> >   
> >   include/uapi/linux/capability.h |  1 +
> >   kernel/capability.c             | 45 +++++++++++++++++++++++++++++++++
> >   kernel/ksysfs.c                 | 18 +++++++++++++
> >   3 files changed, 64 insertions(+)
> > 
> > Best regards and thank you in advance for your reviews.
> > ---
> > [1] man capabilities
> > [2]
> > https://github.com/containerd/containerd/blob/1a078e6893d07fec10a4940a566
> > 4fab21d6f7d1e/pkg/cap/cap_linux.go#L135 [3]
> > https://github.com/moby/moby/commit/485cf38d48e7111b3d1f584d5e9eab46a902a
> > abc#diff-2e04625b209932e74c617de96682ed72fbd1bb0d0cb9fb7c709cf47a86b6f9c1
> > moby relies on containerd code.
> > [4]
> > https://github.com/syndtr/gocapability/blob/42c35b4376354fd554efc7ad35e0b
> > 7f94e3a0ffb/capability/enum.go#L47 [5]
> > https://github.com/opencontainers/runc/blob/00f56786bb220b55b41748231880b
> > a0e6380519a/libcontainer/capabilities/capabilities.go#L12 runc relies on
> > syndtr package.
> > [6]
> > https://github.com/containers/crun/blob/fafb556f09e6ffd4690c452ff51856b88
> > 0c089f1/src/libcrun/linux.c#L35


Best regards.
---
[1] https://github.com/moby/moby/blob/
10aecb0e652d346130a37e5b4383eca28f594c21/contrib/check-config.sh



  reply	other threads:[~2021-12-28 13:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27 20:54 [RFC PATCH v1 0/2] Add capabilities file to sysfs Francis Laniel
2021-12-27 20:54 ` [RFC PATCH v1 1/2] capability: Add cap_strings Francis Laniel
2021-12-27 22:26   ` Casey Schaufler
2021-12-28 13:27     ` Francis Laniel
2022-01-14  0:39       ` Serge E. Hallyn
2022-01-17 14:14         ` Francis Laniel
2021-12-27 20:55 ` [RFC PATCH v1 2/2] kernel/ksysfs.c: Add capabilities attribute Francis Laniel
2021-12-27 22:22 ` [RFC PATCH v1 0/2] Add capabilities file to sysfs Casey Schaufler
2021-12-28 13:34   ` Francis Laniel [this message]
2021-12-29  1:26     ` Casey Schaufler
2021-12-29 20:56       ` Francis Laniel

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=2639798.l7ez0hRiAL@machine \
    --to=flaniel@linux.microsoft.com \
    --cc=casey@schaufler-ca.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).