Linux Documentation
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Willy Tarreau <w@1wt.eu>, Leon Romanovsky <leon@kernel.org>,
	skhan@linuxfoundation.org, security@kernel.org,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
Date: Wed, 13 May 2026 12:29:34 +0200	[thread overview]
Message-ID: <2026051333-puzzle-smokiness-8096@gregkh> (raw)
In-Reply-To: <87wlx8o87g.fsf@trenco.lwn.net>

On Tue, May 12, 2026 at 11:20:51AM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> 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.

> 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 :)

thanks,

greg k-h

  reply	other threads:[~2026-05-13 10:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-09  9:47 [PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI Willy Tarreau
2026-05-09  9:47 ` [PATCH v3 1/3] Documentation: security-bugs: do not systematically Cc the security team Willy Tarreau
2026-05-09  9:47 ` [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug Willy Tarreau
2026-05-09 19:51   ` Shuah Khan
2026-05-11 17:28   ` Greg KH
2026-05-11 18:03     ` Willy Tarreau
2026-05-11 18:39       ` Jonathan Corbet
2026-05-11 20:26         ` Willy Tarreau
2026-05-11 20:42           ` Jonathan Corbet
2026-05-12  5:46             ` Greg KH
2026-05-12  5:54               ` Willy Tarreau
2026-05-12 17:20   ` Jonathan Corbet
2026-05-13 10:29     ` Greg KH [this message]
2026-05-13 11:23       ` Willy Tarreau
2026-05-13 12:52         ` Jonathan Corbet
2026-05-13 13:00           ` Willy Tarreau
2026-05-09  9:47 ` [PATCH v3 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports Willy Tarreau
2026-05-12 17:21   ` Jonathan Corbet
2026-05-13 10:30     ` Greg KH
2026-05-13 11:24       ` Willy Tarreau
2026-05-13 12:53         ` Jonathan Corbet
2026-05-13 12:58           ` Willy Tarreau
2026-05-09 10:52 ` [PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI Leon Romanovsky
2026-05-09 10:56   ` Willy Tarreau
2026-05-12 17:14 ` Jonathan Corbet
2026-05-12 19:13   ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026051333-puzzle-smokiness-8096@gregkh \
    --to=greg@kroah.com \
    --cc=corbet@lwn.net \
    --cc=leon@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=security@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=w@1wt.eu \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox