Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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
Message-ID: <4420381.LvFx2qVVIh@pwmachine>
In-Reply-To: <CAHC9VhTmgMfzc+QY8kr+BYQyd_5nEis0Y632w4S2_PGudTRT7g@mail.gmail.com>
References: <20220725124123.12975-1-flaniel@linux.microsoft.com> <CAHC9VhTmgMfzc+QY8kr+BYQyd_5nEis0Y632w4S2_PGudTRT7g@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

Hi.


Le mardi 16 ao=FBt 2022, 23:59:41 CEST Paul Moore a =E9crit :
> On Mon, Jul 25, 2022 at 8:42 AM Francis Laniel
>=20
> <flaniel@linux.microsoft.com> wrote:
> > Hi.
> >=20
> > First, I hope you are fine and the same for your relatives.
>=20
> Hi Francis :)
>=20
> > A solution to this problem could be to add a way for the userspace to a=
sk
> > 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 kn=
ow
> > kernel capabilities at run time instead of compile time.
>=20
> ...
>=20
> > The kernel already exposes the last capability number under:
> > /proc/sys/kernel/cap_last_cap
>=20
> 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=
=20
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 "contain=
er=20
stack" software should add a new string corresponding to the number of the=
=20
capabilities [1].

The solution I propose would lead to "container stack" software to get rid =
of=20
such an array and to test at runtime, if the name provided by user on the=20
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=20
"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 betwe=
en=20
a new capability added to the kernel (e.g. CAP_BPF) and the time users can =
use=20
it.
More generally, a solution to this problem would be a way for the kernel to=
=20
expose the capabilities it knows.

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


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