[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+rthh-CO287OpGun1-zYc-V632jSHRuwp=Hm0cAnbo1waJKsw@mail.gmail.com>
Date: Tue, 2 May 2017 00:01:55 +0200
From: Mathias Krause <minipli@...glemail.com>
To: Kees Cook <keescook@...omium.org>
Cc: 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 27 April 2017 at 00:04, Kees Cook <keescook@...omium.org> wrote:
> On Wed, Apr 26, 2017 at 2:05 PM, Daniel Cegiełka
> <daniel.cegielka@...il.com> wrote:
>> https://grsecurity.net/passing_the_baton_faq.php
>
> Yeah, I'm sad to see them go. PaX Team was just last night helping
> with some details of PAX_REFCOUNT as it could appear in the upstream
> refcount_t API. I hope they'll still help out from time to time.
>
> It does underscore the critical need to upstream stuff, though. Forks
> of projects might disappear at any time. :(
Now, since grsecurity and PaX went private, quite a few users
(including me) are left in the dark and are, to say the least,
slightly pissed. But not everybody seems to be barking at the right
tree. So I've a few comments and questions for the KSPP.
I think the main reason for Brad and PaX Team to make their work
private is the increased amount of work KSSP has put on them without
providing any valuable work in return. They just don't want to be
forced to maintain and fix-up the variants of grsecurity/PaX features
KSPP lands upstream. And no, the work of KSPP does not make their life
easier, in fact, it makes it harder. Harder for two reasons: First,
the code does not end up verbatim, it's always changed, taken out of
context and "enhanced". Second is the loose of control over the code.
But let me elaborate those two a little further.
The first point directly forces them to think through the upstream
incarnation of a feature, how it differs from their original one and,
for those parts, how to fix them up to work properly to fit their
needs, to fit their security requirements. Those changes generate a
lot of conflicts with their version of the code which takes time to
fiddle out. As happened for __ro_after_init, MEMORY_SANITIZE,
USERCOPY,... which only went in in reduced and modified form,
generating needless work on their side -- from their point of view.
The second point, the loose of control over the code, is even worse.
Not getting any more conflicts when porting the grsecurity/PaX patch
to a new kernel release makes changes to code that used to live in
grsecurity/PaX probably go unnoticed. And, as it seem to be the case,
upstream developers are not always familiar with all the gory details
and might introduce weaknesses and bugs. This not only makes upstream
Linux less secure, it makes grsecurity and PaX less secure, too.
So I can understand why they've done this. Still, with the loose of
the public availability of the patch, Linux security has suffered a
lot. Not only is upstream far far away to reach a level that is
available today in grsecurity and PaX, no, it also won't benefit from
new developments any more. What a great achievement! :(
*sigh*
I think the intention of the KSPP is good -- making vanilla Linux more
secure. But the way it does its work harms overall Linux security. It
does hurt mine, that's for sure! I know the value of grsecurity and
PaX in particular and know how easy it still is to exploit a vanilla
Linux. Features like KERNEXEC and RAP make it almost impossible for an
attacker to abuse a memory corruption bug in the kernel. Many unnamed
features -- unnamed because not under an #ifdef -- make exploiting
use-after-free bugs much less interesting or reduce the race window
for TOCTTOU bugs involving user copy operations. None of this can be
found in vanilla Linux. Probably never will...
So, here's my list of questions for the KSPP:
1/ When will I be able to switch to a vanilla Linux kernel that is
equivalently hardened as a grsecurity/PaX kernel used to be?
2/ Who will maintain this code and how?
3/ Who ensures the coverage and quality won't suffer for each new
kernel release?
Judging from the planed EOL for the v4.9 LTS kernel -- the last one a
grsecurity patch was publicly available for --, there are less than
two years to finish the work for item 1 to ensure a secure and smooth
transition from grsecurity to upstream Linux. Will the KSPP be able to
achieve this?... I have my doubts.
Even if so, item 3 will be a hard problem to solve as the Linux kernel
development model does not support such a tree-wide review point in
the release cycle. Assuming there are people able and willing to judge
and review the code base for required changes (e.g. atomic_t ->
refcount_t changes or function pointer cleanups for RAP), how would
those be able to simply get in those changes at, say, time of rc5? --
without having to argue with a horde of maintainers of the individual
subsystems involved?
Quite a lot of questions. The external patch solved them all by not
having to deal with upstream Linux development and not having the code
available until it's ready. But now it's gone and no adequate
replacement is on the horizon. What will KSPP do about it? I had a
reasonably secure kernel, now it's gone. :(
Regards,
Mathias
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.
