OpenSSL after Heartbleed
OpenSSL after Heartbleed
Posted Apr 29, 2017 12:01 UTC (Sat) by pizza (subscriber, #46)In reply to: OpenSSL after Heartbleed by citypw
Parent article: OpenSSL after Heartbleed
Kees gets credit for the upstreaming work because... wait for it... it is a *ton* of work. The CII/LF is paying for that work, and their PR amounts to little more than "things are better now than before, thanks to this work we're sponsoring."
PaX/etc could have been the ones funded to do this work, and in the process received the credit they claim they deserve. But getting things into the mainline kernel requires an ability to play well with others, something that PaX/etc has repeatedly shown themselves to be utterly incapable of.
Posted Apr 29, 2017 14:27 UTC (Sat)
by citypw (guest, #82661)
[Link] (10 responses)
What's wrong with the reference from PaX/Grsecurity forum just simply reveal the truth? Maybe you are ok with what LF's marketing PR. Those better-than-none PR doesn't make any sense because it's not true. If you think it does, plz check those exploitable kernel bugs( which can be "massive" exp) lately, e.g: CVE - CVE-2017-0358, CVE-2016-1583, CVE-2016-0728, CVE-2017-6074, CVE-2017-7184. PaX/Grsecurity can mitigate tons of exploits does make sense to me.
> But getting things into the mainline kernel requires an ability to play well with others, something that PaX/etc has repeatedly shown themselves to be utterly incapable of.
Is that really what you think? PaX team has been helping upstreaming PaX/Grsecurity in multiple features since the day 1.
Posted Apr 29, 2017 17:16 UTC (Sat)
by flussence (guest, #85566)
[Link] (7 responses)
Posted Apr 30, 2017 3:33 UTC (Sun)
by citypw (guest, #82661)
[Link] (6 responses)
Okidoki, I'm giving you one example here and you can confirm with Kees Cook who is one of main KSPP maintainers:
http://www.openwall.com/lists/kernel-hardening/2017/04/26/17
You can find a lot of evidences about PaX team helped upstreaming stuff in kernel-hardening mailinglist:
http://www.openwall.com/lists/kernel-hardening/
> Forgive me if I'm a little skeptical of a project with an absolutely abhorrent track record of shit-flinging in public.
KSPP is the "hero" to most ppl now and it's not the fact. KSPP was supposed to be a good example but everything is too late for now. Can PaX/Grsecurity users get the test patch back? If not, Linux foundation should pay for all of this. From our very "narrow" perspectives( both FLOSS supporter and security consultant), we made our point very clear already:
https://hardenedlinux.github.io/announcement/2017/04/29/h...
Posted Apr 30, 2017 17:02 UTC (Sun)
by flussence (guest, #85566)
[Link] (5 responses)
Who knows, maybe if they got rid of the toxic elements early on they might be earning a profit today.
Posted May 1, 2017 3:58 UTC (Mon)
by citypw (guest, #82661)
[Link] (4 responses)
[1] Linux kernel mitigation checklist:
Posted May 1, 2017 12:47 UTC (Mon)
by pizza (subscriber, #46)
[Link] (3 responses)
Meanwhile, As a SecurityConsultant(tm) you should also know well that outside of the likes of Nuclear weapons, security does not trump all other considerations, and that if grsec was integrated into the Linux kernel tomorrow and every single device updated to use it the day after, it wouldn't make but a small dent in the tide of data breaches, wouldn't have mitigated the likes of heartbleed or shellshock, nor would it prevented the growing pile of botnets running on the trashware we collectively call the IoT -- hardcoded backdoors, anyone?
....What good is a heavily-reinforced steel door to your house if you just leave all your valuables lying on the ground outside?
Posted May 2, 2017 2:51 UTC (Tue)
by citypw (guest, #82661)
[Link] (2 responses)
https://github.com/hardenedlinux/hardenedlinux_profiles/b...
S0rry I'm very practical about security. I wouldn't believe what media/LF/CII bragging about how they are going to improve security in next years if you just see what they've done in past decade. Programmer will make mistakes and introduce more bugs. That's the simple reason why we need mitigation. Fortunately, PaX/Grsecurity is the most effective mitigation we had.
I don't have the problem with upstreaming stuff. How can you explain to the customers about those "massive" exploits defeated KSPP just in a couple of months?
Posted May 2, 2017 10:55 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
What does this have to do with OpenSSL/Heartbleed and grsec's utter inability to mitigate it or its effects?
> S0rry I'm very practical about security.
FWIW, you have yet to actually demonstrate this.
Posted May 2, 2017 14:14 UTC (Tue)
by citypw (guest, #82661)
[Link]
>> S0rry I'm very practical about security.
Posted Apr 29, 2017 19:54 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
I'd be careful about making that argument that "better than nothing" is worthless -- because it applies equally to PaX if you don't turn on every feature it supports.
"All or nothing" (especially when combined with "my way or the highway") is not how anything has _ever_ been merged into mainline Linux.
> Is that really what you think? PaX team has been helping upstreaming PaX/Grsecurity in multiple features since the day 1.
Given that assertion is directly contradicted by PaX's own words on LWN, I'm going to have to respond with [citation needed].
Posted Apr 30, 2017 0:17 UTC (Sun)
by PaXTeam (guest, #24616)
[Link]
[citation needed] ;)
Posted Apr 30, 2017 0:19 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (11 responses)
> something that PaX/etc has repeatedly shown themselves to be utterly incapable of.
[citation needed]
Posted Apr 30, 2017 14:17 UTC (Sun)
by pizza (subscriber, #46)
[Link] (10 responses)
A quick google search for "PaX' site:LWN" came up with this thread from a couple years back:
https://lwn.net/Articles/663591/
There's links in there to several primary sources as well, so it's not just "he said she said" in LWN comments.
If one expands the search to include 'spender' many more results show up -- including this gem in which, inbetween quite a bit of poo slinging, he unequivocally states that he will never accept LF funding:
https://lwn.net/Articles/706310/
All in all, those Google searches produce a substantial body of evidence of "not playing well with others" (and as an added bonus, also strongly implies that the LF is funding Kees' mainlining work. I admit to not trying to fact-check that, but I wasn't the one who made the initial claim..)
Posted Apr 30, 2017 16:30 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (9 responses)
Posted Apr 30, 2017 18:36 UTC (Sun)
by flussence (guest, #85566)
[Link] (2 responses)
That means the good posts are all genuine; the nasty ones are also genuine; and someone with years of obnoxious nitpicking and obtuseness to their name doesn't get to shrug it off by doubling down on feigned ignorance and playing innocent, when results 1 to 150 of 1020 say otherwise.
And because of the immutability and high signal to noise ratio, someone can use this site as a reliable point of reference (or refer their higher-ups to it, if they aren't already reading) when deciding whether to contribute {time,money,word-of-mouth} to a project, or to leave it for the people in hazmat suits to deal with.
Posted Apr 30, 2017 22:56 UTC (Sun)
by amacater (subscriber, #790)
[Link]
Independence, quality - and an archive that doesn't forget - absolutely indispensable.
Posted May 1, 2017 0:49 UTC (Mon)
by PaXTeam (guest, #24616)
[Link]
to be honest, i didn't expect you to practice self-criticism, but hey, maybe you're able to behave better in the future. that said, you didn't answer my questions either...
Posted May 5, 2017 2:05 UTC (Fri)
by tytso (subscriber, #9993)
[Link] (5 responses)
Similarly, a few words about how the CII works. The CII was fundamentally about large companies getting together to donate money into a common pot to help fund work, that couldn't be done by various member company's own engineers. Again, each of the companies decided that it was in their own self-interest to fund work to make Linux and its core infrastructure more secure. This is probably why you didn't hear back from the LF as a small company. It wasn't worth their time to accept small change funding, when the same amount of time could be used to work with a company who was interested in donating half a million dollars or more.
I suspect that if you took a look at the amount of work that is being done by the KSPP, a very large amount of it is being done by engineers who are funded by their companies to work on these features. More importantly, whether these companies are helping the KSPP by assigning engineers to work on it, or by paying contractors to do various bits of works, what's important is this is simply _more_ security work to make Linux better. It is not within the Linux Foundation's power, or any corporate entity's power, to stop work being done by a volunteer or by an engineer working for another company.
What they _can_ do is work together on a solution that is good enough such that interest in supporting a more proprietary solution is decreased. This may be what is going on with grsecurity; as other says, I don't have enough transparency into the motivations of why grsecurity did what it chose to do. But this also no different from what happened when customers stopped purchasing Sun machines and switched from Solaris to Linux. Was Solaris technically better in some ways? Sure! But there is business value more than just "technical superiority". Once an Open Source operating system was good enough that it would work for companies and their customers, the openness was far more important than small, specific points where Solaris might be technologically superior.
The same is certainly true for grsecurity. There are various reasons why companies have not wanted to base their product on a fork of grsecurity. We can debate what those reasons are, or whether those companies are right in having come to those conclusions, but every company has the right to decide for itself where it wants to put development dollars, just as each volunteer can decide where he or she will devote her volunteer energies. If those companies choose to put their energy behind the KSPP, there is nothing intrinsically wrong with it, and it's nothing personal. grsecurity wasn't meeting their needs (and the need is not just absolute security), so they chose to do something else, and to support something else.
I understand that you feel part of the grsecurity community, and so it is easy to feel that this is all a great conspiracy which is somehow evil. That is, I suppose natural, but competition for supporters is a real part of the open source ecosystem. This is something where Linux has won, and NetBSD and Hurd have been, shall we say, less successful at attracting people who might be interested in sponsoring their development work. But again, there was no great conspiracy at work here. Linux was simply better suited for the needs of those companies that chose to support Linux, and to hire Linux developers to work full-time on making Linux better, and the network effect took over from there.
The final thing I will note is that closing off the sources is something that in the long run won't work for the embeeed and IOT market. That's because while grsecurity may have closed off source access on their website, Linux is still open source and under the GPL, which means that they can not prevent their downstream sub-licensees from redistributing the grsecurity changes. So for example, if grsecurity is used in a cell phone, and that cell phone is sold in the stores, anyone can buy the cell phone, request that they get sources to the kernel used in the cell phone, and then they can make it available on their web site. *Nothing* can stop them from doing that; if grsecurity/PaX tried to prohibit this, they would be in violation of the GPL. They could prevent this by choosing not to sell grsecurity to embedded, mobile, or IOT market --- but then (a) they would be cutting off a large segment of their market, and (b) it means, ipso factor, that grsecurity is worthless for those markets, and it becomes yet another reason why all of those companies who are supporting KSPP were right to do so. Montavista tried a similar approach (only making their fork of the kernel available to their direct customers, and no distributing the sources on their web site), but in the long run, that did not prove to be a winning business strategy. I suspect grsecurity/PAX team will find a similar dynamic at work.
Posted May 5, 2017 14:20 UTC (Fri)
by paulj (subscriber, #341)
[Link] (4 responses)
There are a number of entities with this business model, both around the Linux kernel and other GPL software.
Posted May 5, 2017 15:23 UTC (Fri)
by tytso (subscriber, #9993)
[Link] (3 responses)
So for cell phones and IOT devices grsecurity is not the answer. Which is fine, I don't think it ever was the answer, because as a fork, it's not something that could be easily integrated into SOC vendor's fork of the kernel (which are so horrendous that good luck getting them even to build on another architecture; I've had the misfortune having to debug one of these kernels, and never have I seen such a wretch hive of hacks and villainy.)
But it just goes to show that grsecurity is not the answer for millions and millions of Linux systems --- cell phones and IOT devices. The only solution for those devices is KSPP.
Posted May 5, 2017 15:45 UTC (Fri)
by paulj (subscriber, #341)
[Link] (2 responses)
GRSecurity can simply not sell patches to any vendors that intend to resell devices with binaries installed though. Simple.
Posted May 5, 2017 16:37 UTC (Fri)
by tytso (subscriber, #9993)
[Link]
This is certainly their right. And if they can make money doing that, fine. But they have made themselves completely irrelevant to Linux upstream development, and mostly irrelevant to the Linux ecosystem as a whole.
Posted May 5, 2017 17:59 UTC (Fri)
by excors (subscriber, #95769)
[Link]
Not all are, but some are. Not all care about security, but some do (a bit). I suspect there is a strong positive correlation between those groups. The people who would happily violate the GPL to use grsecurity wouldn't bother using grsecurity anyway, while the people who want to do the right thing can't use grsecurity. (The latter people probably wouldn't have used grsecurity anyway (for various reasons like difficulty integrating with obsolete SoC kernels etc) but now there's even less chance.)
OpenSSL after Heartbleed
OpenSSL after Heartbleed
Can you produce any examples? LKML posts, actual patch submissions, anything like that? Forgive me if I'm a little skeptical of a project with an absolutely abhorrent track record of shit-flinging in public.
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
https://hardenedlinux.github.io/system-security/2016/12/1...
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
> What does this have to do with OpenSSL/Heartbleed and grsec's utter inability to mitigate it or its effects?
You didn't answer the question. Btw, I never said PaX/Grsec could mitigate Heartbleed-like issue. Speaking of OpenSSL, I think the media drew your attention on what they want you to see. I was an OpenSSL/GnuTLS maintainer for OpenSuSE/SLES for a while and I know( even I'm not good at crypto stuff) there are potentially bigger impact from some vulns has to be audited and then formed as part of security baseline in some data center. You can google it if your country don't block it though.
> FWIW, you have yet to actually demonstrate this.
Oh, this is so hard that I can't desmonstrate it. You win, congrats;-)
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
[citation needed]
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
One of LWN's biggest draws is it contains a treasure trove of Linux history, culture and politics spanning decades that can't be “selectively enhanced” by PR firms or narcissists in the way social media, Wikipedia, or Amazon product reviews can.
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed
OpenSSL after Heartbleed