[lkml]   [2006]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Parameter-controlled mmap/stack randomization
    Hash: SHA1

    Pavel Machek wrote:
    > Hi!
    >>>>> 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
    >>>>> having
    >>>>> [ ] 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
    >> programs.
    > 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
    explaining it?

    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.
    > Pavel

    - --
    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
    Version: GnuPG v1.4.2.2 (GNU/Linux)
    Comment: Using GnuPG with Mozilla -

    -----END PGP SIGNATURE-----
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-22 22:13    [W:0.026 / U:29.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site