Re: [PATCH] 220.127.116.11 Parameter-controlled mmap/stack randomization
From: John Richard Moser
Date: Mon May 22 2006 - 16:10:03 EST
-----BEGIN PGP SIGNED MESSAGE-----
Pavel Machek wrote:
>>>>> Good. So fix emacs/oracle/pine, and year or so and some time after it
>>>>> is fixed, we can change kernel defaults. That's still less bad than
>>>>> [ ] Break emacs
>>>>> in kernel config.
>>>> Nobody is going to fix emacs/oracle/pine, they don't have to. Nothing
>>>> is making them. The kernel will wait for them so who cares.
>>> No, _you_ have to fix emacs/oracle/pine. You claimed your patch is
>>> interesting for secure distros, so you obviously have manpower for
>>> that, right?
>> RHAT probably fixed Emacs already since it broke on them. Adamantix and
>> Hardened Gentoo are most likely to put manpower into things like pine..
>> they put a lot of work into removing textrels on i386.
>> Oracle we can't do anything about. It's commercial. If we break it,
>> they will recommend running it on Solaris or Windows 2003.
> Well, if RedHat ships randomization, it will make Oracle fix it quite
> quickly :-).
RHAT ships the same mmap() and stack randomization mainline does; plus
heap randomization. paxtest claims RHAT does something like 1 or 2 more
bits of mmap() randomization than mainline does on i386 as of FC5; but
that regression test in paxtest is a bit flakey. It nails the stack
randomization dead on.
I think if RHAT did break Oracle, Oracle would just ship with
PT_GNU_STACK, which enables an executable stack (!) and disables stack
and mmap() randomization (!!). Who would notice anyway? Maybe auditors
looking at every flag set on every binary on the system.
Now, if RHAT had to write SELinux policy, and upped randomization to
better protect Apache, but had to explicitly keep it low for Oracle,
that would be very transparent to the RHAT developers and to policy
auditors. Would anyone notice? Probably not.
If RHAT FORCED Oracle to use higher randomization, it would break.
Oracle Inc. would then recommend against using RHAT, instead advising
the use of Solaris or Win2k3. Why? It's easier to advise migration
than fix code, especially when you can point out exactly what the
platform you broke on changed and prove that it's not really your fault.
>>> As you may have noticed, I'm at receiving end of those bug
>>> reports. And what you propose is actually *worse* than IDE, because at
>>> least you get relatively clear error message when misconfiguring IDE.
>> Yes but when you misconfigure IDE the system doesn't boot. When you
>> turn up randomization too high, everything works but 1 or 2
> Yes, you'll very quickly realize you misconfigured IDE... while stack
> randomization is going to break 2 apps and you'll not know why.
It's a command line option. It happens as soon as you change menu.lst
or lilo.conf or screw with the command line at boot time. Do you want
me to write some kind of Documentation/address-randomization.txt
Remember in the future I want to buff out the command line option (two
short functions, just delete them outright along with the __setup()
below them) for SELinux policy controls. The impacts and possible
problems could be documented right in the SELinux policy controls.
At the very least a user has to do some digging to find out these are
there; then he has to determine what they do and figure out if this is a
good thing. Writing right in the documents, "Turning entropy up too
high may cause certain programs to segfault," will place the more timid
users in a "Let's not touch this" state most of the time; if it doesn't,
they're the ones that break something we warned them would break and
then ask us about it anyway.
>>> For x86-64... why not?
>> On x86-64 he may, if you can convince him it's useful (asserting that
> I do not care much about randomization, sorry. I see it may be useful
> on x86-64, but I do not think configurability helps. Sorry.
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 v18.104.22.168 (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/