Re: [PATCH] 126.96.36.199 Parameter-controlled mmap/stack randomization
From: John Richard Moser
Date: Sun May 21 2006 - 22:50:35 EST
-----BEGIN PGP SIGNED MESSAGE-----
Pavel Machek wrote:
> On So 20-05-06 11:23:47, John Richard Moser wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Arjan van de Ven wrote:
>>> On Fri, 2006-05-19 at 21:00 -0400, John Richard Moser wrote:
>>>> Any comments on this one?
>>>> I'm trying to control the stack and heap randomization via command-line
>>> why? this doesn't really sound like something that needs to be tunable
>>> to that extend; either it's on or it's off (which is tunable already),
>>> the exact amount should just be the right value. While I often disagree
>>> with the gnome desktop guys, they have some point when they say that
>>> if you can get it right you shouldn't provide a knob.
>> This is a "One Size Fits All" argument.
>> Oracle breaks with 256M stack/mmap() randomization, so does Linus' mail
>> client. That's why we have 8M stack and 1M mmap().
>> On the other hand, some things may give us the undesirable
>> situation where-- even on an x86-64 with real NX-bit love-- there's an
>> executable stack. The stack randomization in this case can likely be
>> weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
>> (there's a zillion of these, like inc %eax) up to 4096 bytes. This
>> leaves 1 success case for every 2047 fail cases.
> Maybe we can add more bits of randomness when there's enough address
> space -- like in x86-64 case?
Yes but how many? I set the max in my working copy (by the way, I
patched it into Ubuntu Dapper kernel, built, tested, it works) at 1/12
of TASK_SIZE; on x86-64, that's 128TiB / 12 -> 10.667TiB -> long_log2()
- -> 43 bits -> 8TiB of VMA, which becomes 31 bits mmap() and 39 bits stack.
That's feasible, it's nice, it's fregging huge. Can we justify it? ...
well we can't justify NOT doing it without the ad hominem "We Don't Need
That Because It's Not Necessary", but that's not the hard part around here.
I say that's the max, and let the kernel devs figure out where they
think it "should" be and the sysadmin define where he thinks it "needs
to" be, with policy. For now I can toy with the hooks with the command
line-- I originally wanted that and /proc, but discarded that when Arjan
started talking about too many knobs.
For now I'm not going to simply roll out an
infrastructure-and-SELinux-hooks patch; one step at a time, plus I don't
know HTF to add an SELinux hook and policy control for it. Maybe if I
can get a cleaned-up patch into -mm someone will pick it up and write an
SELinux hook for it.
On a side note, paxtest says FC5 has 19 bits of stack randomization
(Mainline does too-- 8MiB), and it can't seem to decide if it's 8 or 12
bits of mmap() (mainline has 8, paxtest detects 9 or 10....). I was
sure they had more...
What they DO have that I'm waiting to see in mainline is a random heap
base. 'cat /proc/self/maps' changes things around for everything but
/bin/cat, that is nice. This appears to shift around in 16MiB... (12 bits!)
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v188.8.131.52 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/