Date: Wed, 3 May 2017 22:45:19 -0700 From: Kees Cook <keescook@...omium.org> To: Shawn <citypw@...il.com> Cc: Rik van Riel <riel@...hat.com>, Mathias Krause <minipli@...glemail.com>, Daniel Cegiełka <daniel.cegielka@...il.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: It looks like there will be no more public versions of PaX and Grsec. On Tue, May 2, 2017 at 9:50 PM, Shawn <citypw@...il.com> wrote: > The fragmentation of Android eco-system may be inevitable. The whole > chains is too long from ASOP/BSP/Vendors and it affect the security > fix being delivered to the end user. According to my own statistic > from my customers, there will be more than 7 millions of Android phone > will be using some features of PaX/Grsec this year. I've been pushing > those "simplified" mitigation from PaX/Grsecurity to some vendors. > That's why I have to find out what exploitable bugs is possible to > turned to be "massive" exp and which one is being massive used > already. To me, it's obviously my problem solved by PaX/Grsecurity. I > can't wait for Google's hepl to solve the problem. I shared what I > found about "massive" exp with you and other Google folksl at last > linux security summit. I really appreciate you guys helped some > patches goes into AOSP. But it's just a starting point. Maybe in > Google's point of view, everybody should buy the new phone( btw, I > really love Pixel XL). But I have responsible to taking care of old > devices. My concerns aren't limited to just phones, since the pattern of "stick with one kernel version" is endemic in the industry. Even distros are mostly guilty of this, though their production cycle time is much shorter. I'm glad to have people like you working on this, especially in places where it's traditionally not gotten a lot of attention! > Yeah, I know the history. Intel/ARM never credited PaX/Grsecurity > about the contribution of KERNEXEC/UDEREF, which is the origins of > hardware implementation, e.g: SMEP/SMAP in x86, PXN/PAN in > armv7/arm64. I don't blame Spender/PaX team;-) I thank to ARM > maintainers who did those mitigation for arm64. But I thank more to > PaX/Grsecurity who created it from nothing. Yeah, no doubt. The stuff PaX and grsecurity invented was amazing! And I credit them as helping me see that killing individual bugs isn't sufficient for security defense work. > btw: I share the same view with Mathias Krause and other ppl who > really concern the real sense of security. I like KSPP in the 1st > place. But now I lost PaX/Grsecurity test patch. Who should I blame? I > think we made our point very clear here: > > https://hardenedlinux.github.io/announcement/2017/04/29/hardenedlinux-statement2.html Well, there's exactly one group that decided to pull the patches. If you want to assign blame, I think it's clear it falls squarely on their shoulders. To the first point at your URL, there's a lot of inaccuracies. KSPP is an upstream group; CII funds individuals (not the whole of KSPP) that make independent proposals. In fact, the very first CII funded person was ephox from grsecurity. So ... if CII funding contributors to upstream was the problem, then grsecurity created their own problem? That makes no sense. As for "hardly accomplished anything compared to grsecurity" that's a pretty unfair comparison to make. Upstream has been really focusing on this for maybe 2 years at best now? And grsecurity has been doing it for over a decade? And besides, "upstream doesn't have all of grsecurity upstreamed" isn't a reason to blame upstream for grsecurity going private. How can you say "introduced more bugs"? I'd be happy to fix them, if you see them. And as I talked about in my reply to Mathias, of course things look incomplete in upstream: they're being developed like everything else in upstream: incrementally. It is not possible to just fork-lift everything from grsecurity into upstream. It's just not how upstream development works. To this notion that there is some kind of conspiracy by LF to snub grsecurity is just flat out silly. LF isn't upstream (though, sure, they support a lot of the work). Upstream developers can't control what or how LF says things (and few of us have time to deal with that). If you look at things in upstream that came from grsecurity, you'll see plenty of credit given. That sure seems like upstream "revealing the truth to the public". Look at the copyright notices in the gcc plugins, in mm/usercopy.c, and the notes in the Kconfigs, and the commit messages. Look at my own blog posts covering the features, look at the KSPP wiki page. The vast majority of things attributable to grsecurity, do, in fact, give credit. So upstream certainly isn't "blatantly stealing credit from grsecurity", so why would LF? And if this single PR statement from LF is still seen as a sudden marketing war against grsecurity, then I would ask "How is making the patches private the solution?" Grsecurity has spent over a decade mocking and berating upstream (just look at LWN), so how does a single article from LF suddenly undo all their work to differentiate themselves? This whole line of reasoning is convoluted, and frankly, has absolutely nothing to do with upstream's efforts to protect Linux users. It'd be nice if I could convince you otherwise (see my reply to Mathias), but upstream hasn't "created more work" for grsecurity. And even if you still believe that, making their patches private doesn't reduce the amount of work they have to do. It just forces people to pay them. You later speak of philosophy, so let me ask you: if they've forced their users to pay for access because their features were being upstreamed, then they do not want these protections available to everyone, they want them available only to those who would pay for them. To me, though, it still can't be this simplistic. They've mostly rejected spending free time to upstream things, they've mostly rejected being paid to upstream things, and their efforts to be paid to just work on grsecurity in the open (see the CII thread from a while back) haven't worked, or are insufficient in some way. What is it that grsecurity wants? It looks very much like they want to stay a fork and be paid for it. I certainly can't blame them for this; upstreaming is hard and as Mathias says, they lose a certain level of control over the results. Fundamentally, it's their time; they can do whatever they want with it. And looking to be paid for your time is of course perfectly sensible. But if this desire to stay a fork is true, then their primary goal is NOT protecting as many people as possible, it's protecting a subset of people as perfectly as they can. Again, this is fine. Upstream and grsecurity can coexist in this state (since again, upstreaming doesn't increase their work), and this was the state for over a decade. But suddenly grsecurity went private. So it would appear that grsecurity couldn't make enough money with their patches staying public, so they've made them private. If that's true, then it means that everyone who was using grsecurity but wasn't a sponsor of grsecurity's work holds some level of responsibility for grsecurity's decision. It could be argued that upstream is "using grsecurity but wasn't a sponsor", but this would be missing an important point: upstream's contribution to grsecurity is Linux itself, which has giant value. (And for my part personally, I did everything I could to pay grsecurity, and succeeded a couple times over the years.) With this we have come back around to looking at the GPL, which you mentioned. This is specifically what the GPL was created to protect against. Why hasn't grsecurity paid money to the tens of thousands of contributors to the Linux kernel? Because they don't have to, and that is part of the understanding about using the GPL for a project: everyone contributes what they can, and everyone benefits. And if there are forks, people can use each other's work so no one is risking being in a situation where someone is unfairly benefiting from someone else's work. You had invoked RMS, so, here we are. It looks like grsecurity has gone private because upstream started exercising the princples of the GPL to expand how many upstream users would benefit from grsecurity's work in the same way grsecurity's users benefited from upstream's work. In answer to "who should I blame?" I'd say this is squarely on grsecurity, not anyone else. They've chosen to benefit from upstream's future work without making their future work available to upstream. But maybe this is all wrong. Neither of us can speak for grsecurity, nor know their motivations. I've always tried to avoid these kinds of discussions for that very reason, and to stay focused on the technical work. I can only truly speak for myself. I was faced with a seemingly simple problem: Linux users need to be protected, the vast majority of Linux users run upstream-derived kernels, but many of the best defenses lived in grsecurity. What I'd learned from working at an industry group (OSDL, the pre-LF), working at a distro (Canonical on Ubuntu), and now working on devices and services (Google), is that engineering teams in most places won't risk basing their work on a fork of upstream, whether it be support concerns, cost concerns, complexity concerns, or whatever. At the end of the day, it was clear that the only path forward was to focus upstream on the same defense principles grsecurity espoused, and to then start porting or creating these kinds of defenses in upstream. (Which is the very thing grsecurity told upstream to do at the first Linux Security Summit in 2010!) Doing this work was very time consuming, so I tried to collect interested people together to work under a single umbrella to help change the upstream culture, examine flaws, port or invent defenses, test, document, etc. So, in the end, I can't speak to grsecurity's true motivations, but I can speak to mine, and what I'd like upstream to be doing: protecting as many Linux users as completely as possible. What's possible in upstream differs from what was possible in grsecurity, so no one should expect the same things between the two. Comparing the two projects is fraught with error, and blaming anyone other than grsecurity for going private is ridiculous. > Agree! I'm afraid I can't help much on upstream because that's not my > customer want in short-term. S0rry, my idealist side never fit in > KSPP. Sure, understood. I'm delighted you've spent time getting kernel hardening stuff landed in AOSP, though; for vendors that can be convinced to care about backporting these things, it's great to have a place to point to for them to get your work! And it's fine not to contribute to upstream, since luckily there will be some people who can. Upstream will continue to work on security defenses, but at the very least, it'd be nice if people would be constructive in their criticisms. We've gone over a decade with grsecurity's frequently toxic rhetoric only alienating people instead of productively working together to reach what should be the common goal of security work: defending users. -Kees -- Kees Cook Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.