adding CAP_RESERVED_# bits

[Luigi Semenzato]

On Fri, Jun 6, 2025 at 1:42 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>
> 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 with your assessment of danger, but then the choice is between
maintaining a set of patches reliably, or not being able to do this at all
(when all bits are exhausted).

I can't say if in this case protecting developers from self-hanging
trumps the convenience of the feature.  I would say no, because
developers who maintain kernel patches for their product already
have infinitely many self-hanging opportunities.  But it's subjective.

> >
> > 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!
> >>>