oss-sec mailing list archives
Re: linux-distros list policy and Linux kernel
From: Greg KH <greg () kroah com>
Date: Tue, 17 May 2022 13:52:21 +0200
On Tue, May 17, 2022 at 01:10:16PM +0200, Jason A. Donenfeld wrote:
This brings us back to the original topic of this (sub-)thread: do public fixes make security vulnerabilities manifest to the public? I guess it depends on who you consider to be the public. If you're speaking from the perspective of placating customers and taking care of some commercial bottom line, the answer is no. No public PR situation coming your way, so no work to be done, vulnerability doesn't exist yet. But if you're speaking from the perspective of whether attackers now are aware of the bug and can write exploits for it -- that is, a real threat model -- then the answer is obviously yes, if the fix is public, the bug is public. So when I read in this thread calls for extending embargoes until the vulnerability is "disclosed" in some sort of announcement (that is, PR), rather than just until the public git fix, it seems plain that the end goal is a messaging or communication one, rather than a security one. On the surface, delaying the release of a vulnerability until it's had time to reach customer systems sounds like a good idea. But zoom in a little bit and you quickly realize that the vulnerability has *already* been released to attackers who read commit logs, and the thing we're talking about delaying is an official announcement. It turns out, attackers don't care about your official announcements; the marketing team does.
As you know, there are different "grades" of attackers. There's a huge range from "run metasploit that I just downloaded" to "look at this kernel change and figure out how to abuse the system that does not have it". By delaying a small bit of time from publically posting a patch to telling the world that "hey, that was a security fix over there" that allows the community that works in the public added time for review and testing as our testing infrastructure that is NOT public is quite limited and reviews are limited given the huge range of needed developers to do that review. That delay can allow users to have the fix on their system first before the "metasploit" package is updated to attack it, which reduces the amount of vulnerable systems out there. Yes, it does not solve the "prevent readers of all commits" issue, but I don't know what we can really do about that except switch to a closed source development model, which isn't a good thing overall anyway. So it's just a delay, not a "never disclose" issue here. Is a delay good or not? Personally I think it is, but as you say here, others might not think so.
And as I understand it, the Openwall mailing lists have never been about enabling companies to better control their messaging. They've been about a deterministic embargo & disclosure process, to strike the right balance of letting people coordinate privately when needed, and then letting various parties make the best decisions they can once the cat is out of the bag. Should the distros@ policy change to be more PR-friendly, or should it stay true to its security policy ideals?
I don't think it's a "PR-friendly" issue here, it's about how best to develop and ship secure systems as that's what the linux-distros members are responsible for. The linux-distros group needs to talk about this and come up with what they are going to do for this issue as it is their members that has to define their ideals and how to follow them best. thanks, greg k-h
Current thread:
- linux-distros list policy and Linux kernel Solar Designer (May 15)
- Re: linux-distros list policy and Linux kernel Igor Seletskiy (May 15)
- Re: linux-distros list policy and Linux kernel Anthony Liguori (May 15)
- Re: linux-distros list policy and Linux kernel Jason A. Donenfeld (May 16)
- Re: linux-distros list policy and Linux kernel Thadeu Lima de Souza Cascardo (May 16)
- Re: linux-distros list policy and Linux kernel Greg KH (May 16)
- Re: linux-distros list policy and Linux kernel Seth Arnold (May 16)
- Re: linux-distros list policy and Linux kernel Greg KH (May 16)
- Re: linux-distros list policy and Linux kernel Jason A. Donenfeld (May 17)
- Re: linux-distros list policy and Linux kernel Greg KH (May 17)
- Re: linux-distros list policy and Linux kernel Jeremy Stanley (May 17)
- Re: linux-distros list policy and Linux kernel Thadeu Lima de Souza Cascardo (May 17)
- Re: linux-distros list policy and Linux kernel Thadeu Lima de Souza Cascardo (May 16)
- Re: linux-distros list policy and Linux kernel Vegard Nossum (May 20)
- Re: linux-distros list policy and Linux kernel Solar Designer (May 22)
- Re: linux-distros list policy and Linux kernel Sam James (May 22)
- Re: linux-distros list policy and Linux kernel Greg KH (May 22)
- Re: linux-distros list policy and Linux kernel eduardo vela (May 23)
- Re: linux-distros list policy and Linux kernel Mickaël Salaün (May 24)
- Re: linux-distros list policy and Linux kernel Greg KH (May 24)