[lkml]   [2022]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC PATCH v4 0/2] Add capabilities file to securityfs

First, I hope you are fine and the same for your relatives.

Capabilities are used to check if a thread can 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

The delay between adding a new capability to the kernel and this
capability being used by "container stack" software users can be long.
Indeed, CAP_BPF was added in a17b53c4a4b5 which was part of v5.8 released in
August 2020.
Almost 2 years later, none of the "container stack" software authorize using
this capability in their last stable release.
The only way to use CAP_BPF with moby is to use v22.06.0-beta.0 release which
contains a commit enabling CAP_BPF, CAP_PERFMON and CAP_CHECKPOINT_RESTORE [7].
This situation can be easily explained by the following:
1. moby depends on containerd which in turns depends on runc.
2. runc depends on which is golang package to
deal with capabilities.
This high number of dependencies explain the delay and the big amount of human
work to add support in the "container stack" software for a new capability.

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:
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 "file" is read-only and its content is the capability number associated with
the capability name:
root@vm-amd64:~# cat /sys/kernel/security/capabilities
root@vm-amd64:~# wc -c /sys/kernel/security/capabilities
698 /sys/kernel/security/capabilities
So, the "container stack" software just have to read this file to know if they
can use the capabilities the user asked for.
For example, if user asks for CAP_BPF on kernel 5.8, then this capability will
be present in the file and so it can be used.
Nonetheless, if the underlying kernel is 5.4, this capability will not be
present and so it cannot be used.

The kernel already exposes the last capability number under:
So, I think there should not be any issue exposing all the capabilities it
If there is any, please share it as I do not want to introduce issue with this
Also, the data exchanged with userspace are less than 700 bytes long which
represent 17% of PAGE_SIZE.

Note that I am open to any better way for the userspace to ask the kernel for
known capabilities.
And if you see any way to improve this series please share it as it would
increase this contribution quality.

Change since:
* Use securityfs_create_file() to create securityfs file.
* Use a char * for cap_string instead of an array, each line of this char *
contains the capability number and its name.
* Move the file under /sys/kernel/security instead of /sys/kernel.

Francis Laniel (2):
capability: Add cap_string.
security/inode.c: Add capabilities file.

include/uapi/linux/capability.h | 1 +
kernel/capability.c | 45 +++++++++++++++++++++++++++++++++
security/inode.c | 16 ++++++++++++
3 files changed, 62 insertions(+)

Best regards and thank you in advance for your reviews.
[1] man capabilities
moby relies on containerd code.
runc relies on syndtr package.

 \ /
  Last update: 2022-07-25 14:43    [W:0.058 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site