adding CAP_RESERVED_# bits

[Casey Schaufler]

On 6/6/2025 1:11 PM, Luigi Semenzato wrote:
> On Fri, Jun 6, 2025 at 11:32 AM Casey Schaufler <casey at schaufler-ca.com> wrote:
>> On 6/6/2025 10:57 AM, Luigi Semenzato wrote:
>>> Recently I inquired about the decision process for adding a CAP_DRM
>>> bit to capability.h (to become DRM master).  It occurred to me that
>>> the process for adding ANY bit would be fraught with controversies (to
>>> say the least).
>>>
>>> So I looked into maintaining a patch in our own kernel sources, but
>>> that was surprisingly messy due to the build-time dependencies of
>>> capability.h and the way we maintain and share sources internally for
>>> multiple kernel versions.  This would have been quite simple if there
>>> were a few reserved bits, such as CAP_RESERVED_0, ..,
>>> CAP_RESERVED_<N-1> with, say, N=3.
>>>
>>> Would this also be controversial?
>> Imagine that there was a CAP_RESERVED_0, and that Fedora used it
>> for DRM master control, Ubuntu used it for unsigned module loading,
>> an android used it to control making the battery explode. How could
>> you write applications so that their use of CAP_RESERVED_0 could be
>> considered safe?
> Sorry, I neglected to mention that I am thinking of embedded systems
> where the vendor provides both the OS and the executables, with no
> provision for installing additional executables.  ChromeOS is like that.

I have worked on embedded systems, and don't believe that the problem is
any less serious for them. One aspect of embedded system development is
that kernel versions don't change for years, and then take huge version
updates. That will often require updates to applications and libraries,
which have also evolved over time. We saw this with the introduction of
systemd, where the model for launching privileged services changed radically.
Any assumptions about the use of "reserved" capabilities would be dangerous
when the eventual upgrade occurs. Especially if the vendor of the embedded
system has a different set of developers than they did for the previous
release.

>
> I agree that major general-purpose distributions would not benefit
> from this.  So the question is whether it is worth sacrificing those
> bits for easier security setups on embedded systems (and being
> able to do it at all when eventually all bits are assigned).
>
>>> Thanks!
>>>