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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 Aug 2022 08:49:56 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Paul Moore <paul@...l-moore.com>,
        Francis Laniel <flaniel@...ux.microsoft.com>
Cc:     linux-security-module@...r.kernel.org,
        Eric Biederman <ebiederm@...ssion.com>,
        Serge Hallyn <serge@...lyn.com>,
        James Morris <jmorris@...ei.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:BPF [MISC]" <bpf@...r.kernel.org>,
        casey@...aufler-ca.com
Subject: Re: [RFC PATCH v4 0/2] Add capabilities file to securityfs

On 8/17/2022 7:52 AM, Paul Moore wrote:
> On Wed, Aug 17, 2022 at 7:53 AM Francis Laniel
> <flaniel@...ux.microsoft.com> 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@...ux.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 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.

On the other hand, it's possible that capabilities are a failure,
and that any effort to make them easier to use is pointless.

>  - and I'm
> guessing there isn't due to the lack of comments - I don't think this
> is something we want to add to the kernel, especially since the kernel
> doesn't really care about the capabilities' names, it's the number
> that matters.
>