linux-kernel - Re: [RFC PATCH v4 0/2] Add capabilities file to securityfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 Aug 2022 13:53:21 +0200
From:   Francis Laniel <flaniel@...ux.microsoft.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     linux-security-module@...r.kernel.org,
        Casey Schaufler <casey@...aufler-ca.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        Serge Hallyn <serge@...lyn.com>,
        James Morris <jmorris@...ei.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:BPF [MISC]" <bpf@...r.kernel.org>
Subject: Re: [RFC PATCH v4 0/2] Add capabilities file to securityfs

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@...ux.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