From: Daniel Micay <danielmicay@gmail.com>
To: PaX Team <pageexec@freemail.hu>,
Mathias Krause <minipli@googlemail.com>,
Kees Cook <keescook@chromium.org>
Cc: Daniel Cegielka <daniel.cegielka@gmail.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [kernel-hardening] It looks like there will be no more public versions of PaX and Grsec.
Date: Thu, 11 May 2017 12:30:59 -0400 [thread overview]
Message-ID: <1494520259.1168.2.camel@gmail.com> (raw)
In-Reply-To: <5913BD53.14417.3F7C9BC9@pageexec.freemail.hu>
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.
next prev parent reply other threads:[~2017-05-11 16:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-26 21:05 [kernel-hardening] It looks like there will be no more public versions of PaX and Grsec Daniel Cegiełka
2017-04-26 22:04 ` Kees Cook
2017-05-01 22:01 ` Mathias Krause
2017-05-02 0:09 ` Rik van Riel
2017-05-02 14:46 ` Shawn
2017-05-02 18:55 ` Kees Cook
2017-05-03 4:50 ` Shawn
2017-05-03 18:56 ` Rik van Riel
2017-05-03 19:36 ` Daniel Micay
2017-05-04 5:45 ` Kees Cook
2017-05-04 6:47 ` Lionel Debroux
2017-05-05 19:54 ` Kees Cook
2017-05-04 14:11 ` Shawn
2017-05-04 16:03 ` Greg KH
2017-05-04 17:12 ` Shawn
2017-05-04 17:23 ` Greg KH
2017-05-02 21:16 ` Mathias Krause
2017-05-02 21:50 ` Casey Schaufler
2017-05-02 22:57 ` Kees Cook
2017-05-03 19:02 ` Rik van Riel
2017-05-03 19:27 ` Daniel Micay
2017-05-02 0:39 ` Olof Johansson
2017-05-02 0:44 ` Casey Schaufler
2017-05-02 0:54 ` Kees Cook
2017-05-11 1:24 ` PaX Team
2017-05-11 16:30 ` Daniel Micay [this message]
2017-05-11 18:02 ` Kees Cook
2017-05-12 11:34 ` Hunger
2017-07-31 13:38 ` Solar Designer
2017-05-02 11:11 ` David Gens
2017-05-02 21:27 ` Mathias Krause
2017-05-03 8:59 ` David Gens
2017-05-03 19:10 ` Rik van Riel
[not found] <1788778362.1495506.1493751985632.ref@mail.yahoo.com>
2017-05-02 19:06 ` Lionel Debroux
2017-05-02 22:35 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1494520259.1168.2.camel@gmail.com \
--to=danielmicay@gmail.com \
--cc=daniel.cegielka@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=minipli@googlemail.com \
--cc=pageexec@freemail.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.