Basically a few people have tried in the past but Linux core devs are against large patches. And if you look at old threads [1] where people have attempted to break it up into small patches the core devs have been disinterested.
Just to be clear we're talking about many 2003-era exploit mitigation techniques not being adopted into the kernel. And as a side effect every year there are countless vulnerabilities that come out - for which proactive mitigations with up-to-date PoC's have existed for years.
Greg KH basically said in that thread that it would need to be broken up into tons of small patches. Then each patch will have to be submitted and go through the massive politics of getting it upstreamed. This would require a full-time paid team of people doing it, since Linux foundation or similar organizations don't seem to think it's worth paying for a team of security experts themselves to do similar work hardening the kernel.
Additionally, a long time ago (before grsec I believe) the person (or team) behind PaX, whose code is now a significant percentage of GRSecurity, is anonymous and the Linux core refused to accept patches from anonymous developers.
"I'm glad to help out with this if you can
point me at specific examples of things that should be changed."
Doesn't sound the least bit snarky. Submitting small patches isn't unreasonable, and GRSecurity-inclined people would do well to play nice with the kernel dev process.
Totally agree. His reply is an overly polite response to a rather snarky rant on why the Linux devs should just shut up and accept the author's massive merge. Giant projects like the Linux kernel just don't work that way.
No one in that thread is recommending the Linux devs take the monolithic GRSecurity patches flat out. If you read the originally linked thread Daniel explains why it can't be accepted this way nor does he propose it should.
Rather attempts to submit it in smaller patches have been met with disinterest. As well as the fact security in general has the appearance of being sidelined by the core developers - which has created a large disincentive for developers interested in getting GRSecurity upstreamed from even trying (again).
I still really can't figure out how you characterised that particular post as 'snarky'. You complain of 'massive politics', but you're contributing to it with heavy mischaracterisations like that, turning an apologetic, helpful, and informative email into 'a snarky reply'.
A singular email example will always be missing a lot of context. Just because someones tone is nice and friendly doesn't mean there isn't a ton of subtext to what is being said. I'll give a few examples:
1. Saying that since no one has yet "paid for a team of people to do it" then it "must not be worth doing"
2. Sarcastically using info leak in quotes (see KASLR post in my original email for context on info leaks)
3. Repeatedly saying: if you discover a problem "I can help out with that" or "just let me know" when there is a long history of people doing exactly that and linux core devs including Greg K H largely ignoring them.
Etc, I could go on.
And this is all politics. I never said I was apolitical in the posts above. The whole reason people are saying it would take a team of people to submit patches is because politics.
Saying that since no one has yet "paid for a team of people to do it" then it "must not be worth doing"
Except that it's much less declarative than you're stating ('kind of implies' is pretty far from 'must'), and even has an emoticon added to indicate commiseration: "kind of implies that no one thinks it is worth doing :(". I agree that context can be missing, but at the same time, you shouldn't be significantly changing the visible context like that - you seem to be more about projecting your own issues rather than reading what's on the page when you do that.
Well speaking of projections, I am not pointing to the lack of politeness, nor politics, as the problem in itself here.
I remarked on his snarkyness simply because it indicative of the problem: there has been a long history of dismissiveness during any discussion of upstreaming PaX/grsec-style mitigations. So considering it is not being taken seriously we will continue to enjoy the side-effects for the foreseeable future.
Maybe the grsec people should better communicate the advantage. I suggest taking each CVE and listing whether it would have been mitigated by running a grsec kernel, and compare it to something else (selinux or whatever)
If there is a kernel privilege escalation then SELinux can be disabled as Spender loves to demonstrate https://www.youtube.com/watch?v=WI0FXZUsLuI GRSec does includes it's own MAC system as an alternative to SELinux but that is only a small part.
PaX/grsec is in a different class of mitigation. I don't really know any competitors besides other implementations of small subsets by different operating systems or hardware manufacturers.
To your other point, I don't think anyone who has been following Linux security for any amount of time thinks that Spender or PaX are in need of proving themselves.
> To your other point, I don't think anyone who has been following Linux security for any amount of time thinks that Spender or PaX are in need of proving themselves.
No major distro carries the patch, and the kernel devs don't want to merge it as it is.
A change in tactics is needed - make it easier for everyone to see how much better things with grsec are. The tweets are good, a summary of those tweets would be better.
I don't think these links speak well for the patches you are talking about. I see a number of instances where the patches are being rejected for legitimate quality issues. It is pointed out that for PowerPC one piece doesn't compile with -Werror, and a bunch of configuration ifdefs no longer build. For ptmx_fops it is pointed out that the old code is better encapsulated and more maintainable if the ops structure gets new members. I did not see this answered. A lot of the diffs insert the "const" keyword in kind of unusual and unconventional places without much explanation, and without looking too deeply I kind of doubt it's the only place it can go to achieve the desired effect. This seems to be confusing reviewers on the thread because they are unused to the pattern. (It's much less of a wtf to see the whole vtable declared const than the individual function pointers, for example.)
Then to get all smug about it and call politics on people for doing a code review, rather than fix the patches or communicate their importance better... They could be doing good work but I don't think they come off well in these threads.
Does systemd even work w/patched grsec kernel? Last I heard Spender was considering writing a security module to get deep hooks into the kernel to handle systemd, so I assumed systemd killed off any hope of more grsec/pax patches making it upstream.
I've tried running the grsec kernel on Arch a few times, and I've never gotten it to boot once, it usually just panics immediately. In the same way openSSL was a base of nobody wanting to invest in covering your own ass, there is no interest in having a legitimately secure kernel the way grsec proposes, and even in Arch there are only a few people working on it and while it is in the official repos it really should be in the stock kernel if they wanted to send a message.
Really I think it comes down to territoriality. If there was no 'grsecurity' or 'PaX' name or team or whatever, and it was just a random dev submitting a simple feature, they would accept it. But when this other entity comes trying to improve upon their flawed system, suddenly ego gets involved.
I don't mean to rag too hard on the core devs, but many of their decisions are based on gut instinct, which is very frequently misguided or wrong (heuristics are evolved for reacting quickly to emergencies, not making logical decisions). Grsec should have been introduced into the mainline years ago. The Linux kernel's security track record is embarrassing.
I think its entirely reasonable for Linux devs to not accept patches from anonymous developers.
I value my privacy more than most. But when you are contributing code to a public project used all over the world by millions of people, you should at least be willing to identify yourself, or have very good reasons for not doing so. And that's before we get to the nontrivial copyright issues.
Even if that is the case for whatever legal reason just because they don't accept patches from PaX directly doesn't mean they can't provide their own implementations.
I don't think anyone should have to identify themselves in order to contribute to open source, but I will grant you the copyright issues.
The person or entity submitting the code should be irrelevant. Exacting code review and testing establish the code as trustworthy or compromised, not the identity of the author.
And you can see Greg K H (a linux core dev) snarky reply here: http://article.gmane.org/gmane.comp.security.oss.general/150...
Basically a few people have tried in the past but Linux core devs are against large patches. And if you look at old threads [1] where people have attempted to break it up into small patches the core devs have been disinterested.
Just to be clear we're talking about many 2003-era exploit mitigation techniques not being adopted into the kernel. And as a side effect every year there are countless vulnerabilities that come out - for which proactive mitigations with up-to-date PoC's have existed for years.
Greg KH basically said in that thread that it would need to be broken up into tons of small patches. Then each patch will have to be submitted and go through the massive politics of getting it upstreamed. This would require a full-time paid team of people doing it, since Linux foundation or similar organizations don't seem to think it's worth paying for a team of security experts themselves to do similar work hardening the kernel.
Additionally, a long time ago (before grsec I believe) the person (or team) behind PaX, whose code is now a significant percentage of GRSecurity, is anonymous and the Linux core refused to accept patches from anonymous developers.
Also for a more meta-discussion on how security is handled by the core devs see Spenders summary here in "KASLR: An Exercise in Cargo Cult Security" https://forums.grsecurity.net/viewtopic.php?f=7&t=3367
[1] Spender links to old threads here where people tried breaking it up and submitting small patches:
https://twitter.com/grsecurity/status/541797486479028225
https://twitter.com/grsecurity/status/541797673419145217
https://twitter.com/grsecurity/status/541797780482977792