adding CAP_RESERVED_# bits

adding CAP_RESERVED_# bits

[Luigi Semenzato]

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?

Thanks!

Re: adding CAP_RESERVED_# bits

[Casey Schaufler]

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?

> Thanks!
>

Re: adding CAP_RESERVED_# bits

[Luigi Semenzato]

On Fri, Jun 6, 2025 at 11:32 AM Casey Schaufler <casey@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!
> >

Re: 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@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!
>>>

Re: adding CAP_RESERVED_# bits

[Luigi Semenzato]

On Fri, Jun 6, 2025 at 1:42 PM Casey Schaufler <casey@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@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!
> >>>

Re: adding CAP_RESERVED_# bits

[Paul Moore]

On Fri, Jun 6, 2025 at 1:58 PM Luigi Semenzato <semenzato@google.com> 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?

Yes, and likely rejected too.  The upstream Linux kernel generally
doesn't make any sacrifices to support out-of-tree kernel code, and
giving up precious capability bitmap space would definitely be
considered a sacrifice.

-- 
paul-moore.com

Re: adding CAP_RESERVED_# bits

[Luigi Semenzato]

Sorry for the delay in responding, and thank you so much for
clarifying the Linux priorities.

For our project we ended up hijacking an existing bit which we're
comfortably sure we won't need for that binary (or any binary,
really), plus a seccomp filter.  It's a total hack, but a simple one,
and it beats the alternatives.


On Fri, Jun 6, 2025 at 7:11 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Fri, Jun 6, 2025 at 1:58 PM Luigi Semenzato <semenzato@google.com> 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?
>
> Yes, and likely rejected too.  The upstream Linux kernel generally
> doesn't make any sacrifices to support out-of-tree kernel code, and
> giving up precious capability bitmap space would definitely be
> considered a sacrifice.
>
> --
> paul-moore.com

Re: adding CAP_RESERVED_# bits

[Serge E. Hallyn]

Sorry... why not just request a real capability bit be reserved?

Ok, I see at https://lore.kernel.org/all/?q=Luigi%20Semenzato%20capability
that Casey was suitably cautious.  However, I'd say if we end up needing to do
the painful transition to 128bit caps, we should face that, rather than
make people do ugly hacks.

-serge

On Fri, Jun 27, 2025 at 01:26:54PM -0700, Luigi Semenzato wrote:
> Sorry for the delay in responding, and thank you so much for
> clarifying the Linux priorities.
> 
> For our project we ended up hijacking an existing bit which we're
> comfortably sure we won't need for that binary (or any binary,
> really), plus a seccomp filter.  It's a total hack, but a simple one,
> and it beats the alternatives.
> 
> 
> On Fri, Jun 6, 2025 at 7:11 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Fri, Jun 6, 2025 at 1:58 PM Luigi Semenzato <semenzato@google.com> 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?
> >
> > Yes, and likely rejected too.  The upstream Linux kernel generally
> > doesn't make any sacrifices to support out-of-tree kernel code, and
> > giving up precious capability bitmap space would definitely be
> > considered a sacrifice.
> >
> > --
> > paul-moore.com