oss-sec mailing list archives
Re: linux-distros list policy and Linux kernel
From: Thadeu Lima de Souza Cascardo <cascardo () canonical com>
Date: Tue, 17 May 2022 09:13:08 -0300
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. 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? Jason [1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?id=2505a981114dcb715f8977b8433f7540854851d8
Hey, Jason. Lots of good discussion points there, but let me focus on these last ones, as I think I am able to address them better than the others. Thanks. Notice this is my personal opinion, having been a linux-distros member list for around a year or a bit less. I think you are taking this backwards. The linux-distros policy is not that the fix should be kept private until there is a security disclosure, but that the security implications (that were disclosed to linux-distros) be made public as soon as the fix is public. It is about communication, but not only communication. It is also about process and balancing stability and security. If distros are supposed to include many different fixes in a very short time frame, just in order to hide the security implications of a fix, there are chances of other things breaking because: 1) there are many changes; 2) there was a short time to get them tested. Don't get this wrong. I also agree that a good strategy is to release as many fixes as are identified to go to stable@ as often as possible. But doing it weekly is not feasible for everyone out there. And if distros ship a new kernel release with a single fix without mentioning any security implications, honestly, we are already shouting out to attackers: "hey, we decided this was important enough to include this single fix, look at that!". And it looks like distros are breaking an embargo that was requested. I may be wrong on this, but I have the impression that disclosures are on the hands of the researchers/reporters. They are doing the work you described, going through fixes, syzkaller and other bug reports, and evaluating their security implications. Then, they go to security () kernel org and the policy, as we mentioned, is that the security implications are not disclosed unless the reporter does it. Then, linux-distros/distros has the policy that whatever is posted there must be disclosed to oss-sec after up to 14 days. But it is still the reporter that does it. I think it is important that we are aware of that in order to find out how we could get this better or discuss if we should do it at all. And the status quo today is this: the reporter is the one who does the disclosure, distros won't ship a single fix after they have been told about a security vulnerability (and asked to not communicate its security implications) without a Coordinated Release Date, and distros won't ship hundreds or thousands of fixes in a short time frame just in order to release a security fix and yet hide the security implications. As I read your last question, and recall the initial message that started this discussion, I think people were being true to distros@ security policy ideals when it was asked that reports be made public as fixes were already public. Cascardo.
Current thread:
- Re: linux-distros list policy and Linux kernel, (continued)
- 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)