adding CAP_RESERVED_# bits

[Luigi Semenzato]

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