Re: [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tue, Aug 15, 2023 at 03:17:00PM +0200, Daniel Borkmann wrote:
> On 8/15/23 2:42 PM, Steven Rostedt wrote:
> > On Tue, 15 Aug 2023 13:23:36 +0200 Greg KH 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?

*LOTS* of fixes for driver bugs that can cause security-related issues
are never reported to security@k.o. The author of the bug fix may not
even realize that a security issue is fixed. Those issues may have a
narrower area of impact individually as one would need to run Linux on
specific devices, but collectively they should be considered as
important as other security problems.

> 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.
> 
> >> [1] "Major" includes most government agencies in most countries.

-- 
Regards,

Laurent Pinchart