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
next prev parent 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