[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 May 2017 12:50:39 +0800
From: Shawn <citypw@...il.com>
To: Kees Cook <keescook@...omium.org>
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 Wed, May 3, 2017 at 2:55 AM, Kees Cook <keescook@...omium.org> wrote:
> On Tue, May 2, 2017 at 7:46 AM, Shawn <citypw@...il.com> wrote:
>> On Tue, May 2, 2017 at 8:09 AM, Rik van Riel <riel@...hat.com> wrote:
>>> On Tue, 2017-05-02 at 00:01 +0200, Mathias Krause wrote:
>>>
>>>> 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!
>>>
>>> Yeah, no. The grsecurity people produced patches
>>> that were used on maybe a few tens of thousands
>>> of systems, while the KSPP code will end up
>>> enhancing the security of over a billion Android
>>> devices.
>>>
>> Are you serious think KSPP can solve Android security issue without
>> changing the current Android eco-system? It's about one billion
>> Android device( most are old armv7 based) can be exploited and being
>> used by criminal and BIGBROs( NSA/CIA/PLA/whatever-A*/etc) with low
>> cost. I made hardened PoC( based on PaX + PXN + some code hardening)
>> for Nexus 7 2013 back in 2015. It proved that it can defeat "massive"
>> exp without much perf impact. But I don't see any sign those cellphone
>> vendors would port any KSPP features into the old devices. How about
>> new phone? I ported a couple of KSPP features( all originally done or
>> inspired by PaX/Grsecurity) to Pixel XL:
>>
>> https://github.com/hardenedlinux/armv7-nexus7-grsec
>
> I would love it if things would get rolled out to older phones. This
> isn't something upstream has much influence over, though. But we have
> to look to the future. Eventually all the old phones will get
> replaced, and the new ones will be running newer kernels, etc.
>
> The problem with the phone (and IoT) ecosystem is an entirely separate
> problem. There are some folks chipping away at it, but it's tangential
> to upstream gaining more defenses. I'd also note that this problem
> isn't solved by grsecurity either --- how many phones are running the
> grsecurity patch?
>
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.
>> Google's Pixel/Pixel2 may be the one of few cellphones can getting
>> benefit from KSPP. Otherwise, my own phone is running with much more
>> hardening features than Android O( released in Oct?) but it's still
>> not secure enough to defeat customized exploit.
>>
>>> Those Android devices are more likely to require
>>> hardening, too, since they do not receive security
>>> updates as quickly as the systems maintained by
>>> grsecurity users.
>>>
>> Don't worry about it. PaX/Grsecurity can defeat multiple public
>> exploits without any fix. Maybe some ppl will go to maintain 4.9 LTS.
>
> This is kind of true. RAP was x86_64 only, so it didn't help armv7 nor
> arm64. Hardened usercopy wasn't ported by grsecurity to arm64
> (upstream did that, though it was trivial). UDEREF wasn't ported by
> grsecurity to arm64, ARM filled that gap by inventing the mechanisms
> to provide PAN emulation. There are all kinds of other protections
> aren't arch-specific (e.g. heap hardening). Those would make good
> things to focus on upstreaming if you were interested. CopperheadOS is
> using a bunch of those things already:
>
> https://github.com/CopperheadOS/kernel_google_marlin/commits/nougat-mr2-release
>
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.
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
> So really, upstreaming defenses has really helped the future phone
> ecosystem, even if the "don't update old devices" attitude continues
> to not change with vendors.
>
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.
--
GNU powered it...
GPL protect it...
God blessing it...
regards
Shawn
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.
