On Wed, Aug 17, 2022 at 12:49 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 8/17/2022 9:10 AM, 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, > > True, but it can ask someone what to do, and in that case a string is > much better than a number ... If you are asking a user what to do, that user can just as easily look up the capability list to translate numbers to intent. If your security approach requires a user knowing all of the subtle details around a capability based on 10~15 character string, I wish you the best of luck :) -- paul-moore.com
