The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Willy Tarreau <w@1wt.eu>, Greg KH <greg@kroah.com>
Cc: 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 06:52:00 -0600	[thread overview]
Message-ID: <87ecjfmpzj.fsf@trenco.lwn.net> (raw)
In-Reply-To: <agRfFoMC2Gcu0Esz@1wt.eu>

Willy Tarreau <w@1wt.eu> 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 <w@1wt.eu> 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

  reply	other threads:[~2026-05-13 12:52 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
2026-05-13 11:23       ` Willy Tarreau
2026-05-13 12:52         ` Jonathan Corbet [this message]
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=87ecjfmpzj.fsf@trenco.lwn.net \
    --to=corbet@lwn.net \
    --cc=greg@kroah.com \
    --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