[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <366c82cdbeb4daf06dc441214a69f6cd@cs.tu-darmstadt.de>
Date: Wed, 03 May 2017 10:59:09 +0200
From: David Gens <david.gens@...tu-darmstadt.de>
To: Mathias Krause <minipli@...glemail.com>
Cc: Kees Cook <keescook@...omium.org>,
Daniel Cegiełka
<daniel.cegielka@...il.com>,
kernel-hardening@...ts.openwall.com
Subject: Re: It looks like there will be no more public
versions of PaX and Grsec.
On 2017-05-02 23:27, Mathias Krause wrote:
> On 2 May 2017 at 13:11, David Gens <david.gens@...tu-darmstadt.de>
> wrote:
>> So tell me how exactly a PaX-hardened kernel with a memory-corruption
>> bug
>> prevents an adversary from modifying critical data, such as the page
>> tables
>> in a data-only attack?
>
> It doesn't as it has not mitigation for data-only attacks yet. But
> neither does a vanilla kernel. It's even worse on vanilla Linux where
> the page tables simply can be written to with a write-what-where
> primitive. PaX can, however, protect the page tables from getting
> modified by having them write-protected. So yes, that makes it more
> secure.
>
>> IMHO the "PaX mitigates Memory-corruption" argument
>> is wishful thinking, and now that PaX is gone users cannot fool
>> themselves
>> any longer into thinking "My System is Secure". That awareness is
>> actually
>> good no?
>
> What about KERNEXEC and CONSTIFY taking care of protecting a lot of
> data structures? What about SIZE_OVERFLOW successfully preventing know
> overflow bugs, like the various keys related ones? What about RAP,
> ensuring control flow integrity? That's nothing, you say? Ridiculous.
Nope, I never said that. I said it is insufficient to mitigate memory
corruption.
Actually, KSPP even has the potential to improve things here. Granted,
for the time
being these PaX features are unavailable, but that was a one-sided
political decision,
and blaming others (based on non-factual claims) is not helping.
I guess it would be nice to have a list of features that will be ported
into KSPP,
e.g., sorted by priority, and then users could easily check when to
switch from the
last PaX patches. But thats not how kernel development works
(traditionally), because
developers push features they (or their employers) are interested in.
> Thanks,
> Mathias
Best,
David
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.
