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

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:
> > 
> > > The use of automated tools to find bugs in random locations of the kernel
> > > induces a raise of security reports even if most of them should just be
> > > reported as regular bugs. This patch is an attempt at drawing a line
> > > between what qualifies as a security bug and what does not, hoping to
> > > improve the situation and ease decision on the reporter's side.
> > >
> > > It defers the enumeration to a new file, threat-model.rst, that tries
> > > to enumerate various classes of issues that are and are not security
> > > bugs. This should permit to more easily update this file for various
> > > subsystem-specific rules without having to revisit the security bug
> > > reporting guide.
> > 
> > One thing here:
> > 
> > [...]
> > 
> > > +* **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.

> > As a lower-priority thing, lockdown mode is meant to at least try to
> > provide some stronger guarantees, and lockdown circumvention seems to be
> > normally be viewed as a security bug.  Worth a mention?
> 
> lockdown issues are best discussed on the list where the lockdown people
> are as most of us feel that really isn't a "security" thing at all :)

I don't remember when we last got a report for it but it's not frequent.
Again, I think we should continue to focus on efficiency, i.e. the number
of improperly routed reports we can stop per word written/read.

Willy