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

[Paul Moore]

On Wed, Aug 17, 2022 at 11:50 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> On 8/17/2022 7:52 AM, Paul Moore wrote:
> > On Wed, Aug 17, 2022 at 7:53 AM Francis Laniel
> > <flaniel@xxxxxxxxxxxxxxxxxxx> wrote:
> >> 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@xxxxxxxxxxxxxxxxxxx> 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].
> > Thanks for clarifying things, I thought you were more concerned about
> > detecting what capabilities the running kernel supported, I didn't
> > realize it was getting a string literal for each supported capability.
> > 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 capabilities
> 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 of
> 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
simply accepts a set of capabilities from the user and then checks
those against the maximum supported by the kernel, but once again that
doesn't require a string value, it just requires the application
taking a set of integers and passing those into the kernel when a
capability set is required.  I still don't see how adding the
capability string names to the kernel is useful here.

-- 
paul-moore.com