[kernel-hardening] Trying to get PaX RANDMMAP into the mainstream kernel

[kernel-hardening] Trying to get PaX RANDMMAP into the mainstream kernel

[Anthony G. Basile]

Hi everyone,

I had a brief conversation yesterday with solardiz on
freenode/#openwall.  The topic turned to what other hardening code could
go upstream besides the stuff you guys have already been pushing.  It
would be nice if we could get PaX RANDMMAP in.  It gives better
randomization on mmap addresses, but unfortunately breaks packages which
use pre-compiled headers. [1]

I wrote a little POC program to demonstrate this. [2]  Try running it on
vanilla ubuntu, opensuse and gentoo.  Then try running it on the same
with a hardened kernel with RANDMMAP enabled.

We came across this issue in a hardened gentoo bug. In one of the
comments, pipacs <pageexec@freemail.hu> gives a very complete
explanation of the situation. [3]  I won't repeat it here.

If RANDMMAP does get in, then this would be incentive to the gcc people
to address the limitations of their gch code.  However, the logic works
the other way, so this is also the barrier to getting RANDMMAP upstream.
solardiz had a good idea: have some sysctl in /proc/sys/kernel either
turn it on or off, or allow you to set the amount of randomization.
This eases the impact in a running kernel, so its not something the user
is stuck with once they configure, compile and reboot.

Also, I don't know if people here are familiar with Hedrick's work.  He
has broken up the grsec 50k line monolithic patch into smaller patches
which address each feature individually.  Critical if you want to get
any of this stuff upstream.

BTW, Vasiliy, kudos on your GSoC work.

Refs:

[1] http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
[2] http://opensource.dyc.edu/pub/misc/pch-poc.tgz
[3] https://bugs.gentoo.org/show_bug.cgi?id=301299#c31
[4]
https://www.kernel.org/pub/linux/kernel/people/hedrick/security/README.grsecurity

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [kernel-hardening] Trying to get PaX RANDMMAP into the mainstream kernel

[Vasiliy Kulikov]

Hi Anthony,

On Thu, Aug 25, 2011 at 09:03 -0400, Anthony G. Basile wrote:
> I had a brief conversation yesterday with solardiz on
> freenode/#openwall.  The topic turned to what other hardening code could
> go upstream besides the stuff you guys have already been pushing.

Sure!  The previous stuff was just a part that I've tried to somehow
handle during a short time window.


>  It
> would be nice if we could get PaX RANDMMAP in.  It gives better
> randomization on mmap addresses, but unfortunately breaks packages which
> use pre-compiled headers. [1]

Am I right that the difference is that upstream mmap() respects addr
hint from userspace and PaX ignores it?


> We came across this issue in a hardened gentoo bug.

Were gcc developers informed about the issue?  There is a small
possibility that they don't mind to fix it :)


> If RANDMMAP does get in, then this would be incentive to the gcc people
> to address the limitations of their gch code.  However, the logic works
> the other way, so this is also the barrier to getting RANDMMAP upstream.
> solardiz had a good idea: have some sysctl in /proc/sys/kernel either
> turn it on or off,

Do you mean ignore addr hint or respect it?  I find it too limited and
upstream is likely to NACK it.

As it is only a hint for OS, it could be simply ignored, without any
sysctl.  But as it breaks at least one widespread application, it's
unlikely to be applied by upstream :(


> or allow you to set the amount of randomization.

Agreed.  sysctl is good for containers, which handle ASLR different way.
E.g. some containers run apps which don't need much VA space, but
another container has space critical applications.


> Also, I don't know if people here are familiar with Hedrick's work.  He
> has broken up the grsec 50k line monolithic patch into smaller patches
> which address each feature individually.  Critical if you want to get
> any of this stuff upstream.

Great, I didn't know about it.  I'll look at it very soon.


Thanks,

-- 
Vasiliy