On Wed, Aug 17, 2022 at 12:19 PM Serge E. Hallyn <serge@xxxxxxxxxx> 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@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 > > 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. -- paul-moore.com
