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;
MIME-Version: 1.0
References: <20220725124123.12975-1-flaniel@linux.microsoft.com>
 <CAHC9VhTmgMfzc+QY8kr+BYQyd_5nEis0Y632w4S2_PGudTRT7g@mail.gmail.com>
 <4420381.LvFx2qVVIh@pwmachine> <CAHC9VhSMeefG5W_uuTNQYmUUZ1xcuqArxYs5sL9KOzUO_skCZw@mail.gmail.com>
 <ab1bbd48-c48d-5f5a-f090-428ffd54c07e@schaufler-ca.com> <CAHC9VhTxYaLXFbS6JnpskOkADNbL8BA5614VuK3sDTHW6DE3uQ@mail.gmail.com>
 <20220817161924.GA20337@mail.hallyn.com>
In-Reply-To: <20220817161924.GA20337@mail.hallyn.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Wed, 17 Aug 2022 12:22:49 -0400
Message-ID: <CAHC9VhTUid5i8C+W93Zfc_bWMoo7DsvruJ_85Ty0wWsV7xbb4g@mail.gmail.com>
Subject: Re: [RFC PATCH v4 0/2] Add capabilities file to securityfs
To:     "Serge E. Hallyn" <serge@hallyn.com>
Cc:     Casey Schaufler <casey@schaufler-ca.com>,
        Francis Laniel <flaniel@linux.microsoft.com>,
        linux-security-module@vger.kernel.org,
        Eric Biederman <ebiederm@xmission.com>,
        James Morris <jmorris@namei.org>,
        open list <linux-kernel@vger.kernel.org>,
        "open list:BPF [MISC]" <bpf@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Aug 17, 2022 at 12:19 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> On Wed, Aug 17, 2022 at 12:10:25PM -0400, Paul Moore wrote:
> > On Wed, Aug 17, 2022 at 11:50 AM Casey Schaufler <casey@schaufler-ca.co=
m> wrote:
> > > On 8/17/2022 7:52 AM, Paul Moore wrote:
> > > > On Wed, Aug 17, 2022 at 7:53 AM Francis Laniel
> > > > <flaniel@linux.microsoft.com> wrote:
> > > >> Le mardi 16 ao=C3=BBt 2022, 23:59:41 CEST Paul Moore a =C3=A9crit =
:
> > > >>> 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 userspa=
ce 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" softwar=
e 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 cap=
abilities
> > > >> 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 se=
t.
> > > >>
> > > >> Sadly, each time a new capability is added to the kernel, it means=
 "container
> > > >> stack" software should add a new string corresponding to the numbe=
r of the
> > > >> capabilities [1].
> > > > Thanks for clarifying things, I thought you were more concerned abo=
ut
> > > > detecting what capabilities the running kernel supported, I didn't
> > > > realize it was getting a string literal for each supported capabili=
ty.
> > > > Unless there is a significant show of support for this
> > >
> > > I believe this could be a significant help in encouraging the use of
> > > capabilities. An application that has to know the list of capabilitie=
s
> > > at compile time but is expected to run unmodified for decades isn't
> > > going to be satisfied with cap_last_cap. The best it can do with that
> > > is abort, not being able to ask an admin what to do in the presence o=
f
> > > a capability that wasn't around before because the name isn't known.
> >
> > An application isn't going to be able to deduce the semantic value of
> > a capability based solely on a string value, an integer is just as
> > meaningful in that regard.  What might be useful is if the application
>
> Maybe it's important to point out that an integer value capability in
> kernel will NEVER change its string value (or semantic meaning).
>
> The libcap tools like capsh accept integer capabilities, other tools
> probably should as well.  (see man 3 cap_from_text)

Seems like a reasonable thing to me, I would much prefer that than the
approach in this patchset.

--=20
paul-moore.com