All of lore.kernel.org
 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: 33+ 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-13 21:04             ` Jonathan Corbet
2026-05-14  4:32               ` Willy Tarreau
2026-05-14 12:22                 ` Jonathan Corbet
2026-05-14 13:13                   ` 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-13 21:02           ` Jonathan Corbet
2026-05-14  4:34             ` Willy Tarreau
2026-05-14  7:23             ` Greg KH
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.