Date: Thu, 11 May 2017 12:30:59 -0400 From: Daniel Micay <danielmicay@...il.com> To: PaX Team <pageexec@...email.hu>, Mathias Krause <minipli@...glemail.com>, Kees Cook <keescook@...omium.org> Cc: Daniel Cegielka <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. KSPP is going to change without public patches. There was a substantial community built around PaX and grsecurity. Hardened Gentoo, Alpine and Arch Linux all had/have official support integration and a significant number of users. Other people used it on their own. Few of those users are going to have access now so the best we have is upstream work (KSPP) and maintaining stuff downstream if it hasn't landed yet or is blocked by politics, etc. People aren't going to accept only having a 4.9 LTS with the last public patch. New hardware support is already chipping away at the usefulness of that. I agree with a lot of what you're saying, but that doesn't really matter anymore. I care about code, not politics and historical grievances. I think PaX / grsecurity has almost always been on the right side of these feuds but that changed when people trying to improve security upstream by landing changes from PaX / grsecurity or even just new code became the enemy. People get banned from the community (IRC) for even stating that they want to help improve upstream security. I was quite happy with the grsecurity patches so I lacked the motivation to make upstream contributions. I only tried to push things in the right direction on the mailing lists, which ended up getting me banned from a community that I put a lot of time/effort into. Other than the few with access to the commercial patches, the community either has the choice of staying loyal to you and having nothing or using and contributing to the remaining public efforts. In terms of funding contracting out work isn't how companies like Google do things. They hire people and do everything in-house, even if that means losing on lots of talented people not willing to do things their way. CII / OTF are the exception to the rule and then your funding would be subject to politics and could vanish at any time even if you succeed in getting it from them initially. They didn't single out grsecurity for this treatment, it's how they do things in general. We were encouraged to apply for OTF funding for CopperheadOS by people who supposedly had influence there and were rejected based on astoundingly stupid reasons after wasting time on it. AOSP is primarily permissively licensed, so we moved away from FOSS licensing -> non-commercial usage licensing for everything but the kernel due to getting nothing back from it while companies were taking and not giving back. Unfortunately, you don't have that option. I've always tried (and mostly failed) to get changes upstream into AOSP though. I'm not worried about running out of features to implement and it makes it easier to maintain since that stuff doesn't need to keep being ported forward, although there's a lot more time pressure to port than there is for Linux due to how it's released. The VMAP_STACK feature is upstream, so while reinventing KSTACKOVERFLOW was silly and rediscovering the same bugs even more so, that time ended up being wasted and the temporary stability hit was accepted. It's too late now and the upstream feature is going to be perfectly good. KASLR is a weak mitigation, but people decided to spend their time on that and it exists so I don't see the point in not getting the marginal utility it offers rather than disabling it or marginally useful checks in the USERCOPY code via CONFIG_BROKEN_SECURITY, where you're taking something away from your users essentially out of spite. I also don't understand the point of maintaining stuff like KSTACKOVERFLOW and a bunch of other features once the upstream solution works fine. Why keep a separate ASLR implementation with a legacy random number generation scheme vs. a few small changes to the upstream one, etc? https://github.com/thestinger/linux-hardened now exists because I am quite aware of the limitations of upstream work and I don't plan on waiting years to have features like RAP and page table protection. Still, it's only maintainable for us if we actually split everything up and document it which is half of the way to upstreaming everything. It makes sense to try to land as much as possible upstream for free code review / testing and a reduction of the maintenance burden. The goal isn't to upstream as much as possible, but rather than the means to an end which is getting back what we already had available via the work you published. If you can't tolerate people doing stuff like this, you're going to end up considering a lot of your old community as enemies... I don't see what else we are supposed to do. There's no way for the PaX / grsecurity commercial model to work for regular users.
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.