Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug

Willy Tarreau <[email protected]> writes:

> On Wed, May 13, 2026 at 12:29:34PM +0200, Greg KH wrote:
>> On Tue, May 12, 2026 at 11:20:51AM -0600, Jonathan Corbet wrote:
>> > Willy Tarreau <[email protected]> writes:

>> > > +* **Capability-based protection**:
>> > > +
>> > > +  * users not having the ``CAP_SYS_ADMIN`` capability may not alter the
>> > > +    kernel's configuration, memory nor state, change other users' view of the
>> > > +    file system layout, grant any user capabilities they do not have, nor
>> > > +    affect the system's availability (shutdown, reboot, panic, hang, or making
>> > > +    the system unresponsive via unbounded resource exhaustion).
>> > 
>> > That is pretty demonstrably not true, and will likely elicit challenges
>> > at some point.  There are a lot of "make me root" capabilities that
>> > enable users to do all of those things; consider CAP_DAC_OVERRIDE as an
>> > obvious example.  I think that just about all of the capabilities will
>> > enable at least one of those things - that's why the capabilities exist
>> > in the first place.  So I think this needs to be written far more
>> > generally.
>> 
>> You are right, there are more capabilities, but we get bug reports all
>> the time that basically come down to "a user with CAP_SYS_ADMIN can go
>> and do..." which are pointless for us to be handling.  Just got one a
>> few minutes ago, so LLMs are churning this crap out quite frequently.
>> 
>> So any rewording of this to prevent us from getting these pointless
>> reports would be great.
>
> Honestly we're seeing this through the angle of a patch that lists a
> single paragraph but the doc is already becoming quite long. I'm a bit
> afraid of adding long enumerations, or sentences which do not immediately
> translate to something recognizable by reporters. Not that it cannot be
> done, but I think the current situation warrants incremental improvements
> by fixing what doesn't work well. And indeed most of the capabilities
> based reports currently revolve around "I already have CAP_{SYS,NET}_ADMIN
> and ...". That might remain a good start for now.

I definitely wouldn't argue for making it longer, and enumerating all of
the make-me-root capabilities would be silly.  I would consider just
replacing CAP_SYS_ADMIN with "elevated capabilities" or some such.  That
might rule out legitimate reports where some capability provides an
access it shouldn't, but I suspect you could live with that :)

Thanks,

jon