From: Daniel Borkmann <daniel@iogearbox.net>
To: Steven Rostedt <rostedt@goodmis.org>,
Greg KH <gregkh@linuxfoundation.org>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
Jiri Kosina <jkosina@suse.cz>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@
Date: Tue, 15 Aug 2023 15:17:00 +0200 [thread overview]
Message-ID: <47419913-2a5a-2bc1-ece9-cc371d4fefdf@iogearbox.net> (raw)
In-Reply-To: <20230815084253.7091083e@gandalf.local.home>
On 8/15/23 2:42 PM, Steven Rostedt wrote:
> On Tue, 15 Aug 2023 13:23:36 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Tue, Aug 15, 2023 at 12:17:03PM +0200, Vegard Nossum wrote:
>>> I'll throw in another idea: distros@kernel.org.
>>>
>>> A closed list which will be notified by security@kernel.org once they
>>> feel patches for a particular issue are ready for testing/consumption by
>>> distros (and hopefully before the issue is disclosed publicly, if the
>>> reporter still wishes to do that).
>>>
>>> The members and list rules would be totally up to the security team to
>>> decide.
>>
>> As per the lawyers, and government officials we have worked with in the
>> past, having a closed list for preannouncements like this will be
>> either:
>
> I guess the question is, what "preannouncements" are the lawyers worried about?
>
> It looks like Jiri's concern is just to make sure that distros have
> security patches in. Would just a list of "here's the commits that fix
> security issues" be considered a preannouncement, without having any
> reference to *what* security issue they fix? It would basically be a subset
> of the stable tree. That is, anything that came from security@k.o, and does
> not include all the AUTOSEL and other minor fixes that stable pulls in.
Not really answering your question, but the above is also a somewhat misleading
"assurance" for distros. Some security fixes might potentially have come in via
AUTOSEL, and some others might not have been discussed at security@k.o in the
first place. How would you classify which ones of the whole set are relevant
for distros and which ones are not?
Imho, if distros decide to maintain their own trees outside of stable it would
still require manual triaging of the set of stable patches that went into a minor
release (and if in doubt, just cherry-pick the patch) - that's just the cost to
pay for maintaining non-stable base. It's the same issue as discussed in [0].
[0] https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/
>> - deemed illegal in some countries
>> - made to have all "major"[1] Linux users on it.
>
> And if this list only has a list of patches that are already fixed, how
> dangerous is it to not be 100% closed?
>
> I mean, it was pretty obvious that the huge churn with spectre/meltdown
> patches that were being added to the kernel at the late stage of an -rc
> release was fixing "something big".
>
>> Neither of which actually will work out at all, the whole
>> "preannouncement" stuff just is not possible, sorry. I'm amazed that
>> other projects have been able to "get away with it" for as long as they
>> have without either being infiltrated by "the powers that be" or
>> shutdown yet.
>
> Have there been lists shutdown by the powers that be already? Or is this
> just a threat made by the power that be?
>
>> Politics is a rough game, the only way to survive is to not play it for
>> stuff like this.
>>
>> So no, "distros@k.o" isn't going to be possible for the LF to host, and
>> any other group that wants to run such a thing will quickly have these
>> issues as well, it's amazing that linux-distros has been able to survive
>> for as long as it has.
>
> I'll have to talk with some laywers, as I'm curious to what would be
> considered illegal about linux-distros. Are you aware of any government
> specific laws I could go read? I'm not a lawyer, but I've read quite a bit
> of laws that I can usually get an idea of the problem for my own
> references (and my experience is that lawyers don't even know until
> something is settled in court).
>
> Note, linux-distros is not about "Linux users" but "Linux distributors".
> They are not end users but are distributing a product (and having to follow
> all the rules of the GPL and such to do so). They are not users, they are
> part of a supply chain.
>
> How is security@kernel.org different? If the bug is in the kernel, then the
> bug is in the distro. Perhaps if we find a bug in the kernel, we should
> send it to the distro we are using, and not to the Linux community? As Jiri
> said, most people use a distro kernel, and not the mainline or even the
> stable one. Really, if you think about it. The closest product to the user
> is the distro. If someone finds a bug in the kernel, they can see if they
> can exploit a distro with it. If they can, perhaps they should send it to
> the security folks of the distro first. Then the distro can send it to
> security@kernel.org. Maybe this already happens?
I mainly just wanted to chime in on this one and mention that from my past
experience (at least I've seen it couple of times from RH/Canonical) this
will not work overly well.
We had seen users reporting kernel security bugs there and they were stuck
in the security team's triage/bug queue for 3+ months before someone got in
contact with upstream. :-(
Presumably the teams were overloaded when it happened, or the bugs were
misclassified due to lack of domain specific knowledge or they wanted to fix
it themselves but didn't get to it yet.
Had they been reported to s@k.org, then the relevant maintainers/developers
could have been pulled in and it would have been fixed upstream possibly the
same day it got reported.
So my biggest concern with reporting to distro first is that "things get stuck
in the process", unfortunately. The less additional/artificial hops, the better,
imho.
Cheers,
Daniel
> -- Steve
>
>>
>> greg k-h
>>
>> [1] "Major" includes most government agencies in most countries.
>
>
next prev parent reply other threads:[~2023-08-15 13:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 9:28 [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@ Jiri Kosina
2023-08-15 10:17 ` Vegard Nossum
2023-08-15 10:34 ` Jiri Kosina
2023-08-15 11:23 ` Greg KH
2023-08-15 12:42 ` Steven Rostedt
2023-08-15 13:17 ` Daniel Borkmann [this message]
2023-08-15 14:19 ` Laurent Pinchart
2023-08-15 22:04 ` Jiri Kosina
2023-08-15 14:20 ` Catalin Marinas
2023-08-15 14:41 ` Greg KH
2023-08-15 15:04 ` Steven Rostedt
2023-08-15 15:51 ` Greg KH
2023-08-15 15:08 ` Greg KH
2023-08-15 18:46 ` Konrad Rzeszutek Wilk
2023-08-15 19:41 ` Greg KH
2023-08-15 22:13 ` Jiri Kosina
2023-08-15 22:31 ` Steven Rostedt
2023-08-16 14:55 ` Greg KH
2024-02-16 17:14 ` Michal Suchánek
2024-02-16 17:34 ` Greg KH
2024-02-16 18:13 ` Michal Suchánek
2024-02-16 18:16 ` Jiri Kosina
2023-08-15 22:17 ` Jiri Kosina
2023-08-16 14:57 ` Greg KH
2023-08-16 17:22 ` Jiri Kosina
2023-08-16 18:38 ` Vegard Nossum
2023-08-16 15:26 ` Solar Designer
2023-08-25 11:17 ` Donald Buczek
2023-08-29 8:46 ` Miroslav Benes
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=47419913-2a5a-2bc1-ece9-cc371d4fefdf@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=gregkh@linuxfoundation.org \
--cc=jkosina@suse.cz \
--cc=ksummit@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=vegard.nossum@oracle.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).