Hi!
> >>>> On the other hand, some things[1][2][3] 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.
> >
> > Well, making it configurable and pushing hard decision to the user is
> > not right approach, either. I believe we need different
> > per-architecture defaults, not "make user configure it".
>
> Yes, different per-architecture defaults is feasible with configuration
> being possible. I could replace 'int STACK_random_bits=19' with 'int
> mmap_random_bits=ARCH_STACK_RANDOM_BITS_DEFAULT' and that would be
> effective as long as the user doesn't touch it with command line or
> SELinux or whatnot.
>
> It is still possible that ARCH_STACK_RANDOM_BITS_DEFAULT breaks things.
> The current kernel default broke emacs at first I heard; I believe
> we
Well, fix emacs then. We definitely do not want 10000 settable knobs
that randomly break things. OTOH per-architecture different randomness
seems like good idea. And if Oracle breaks, fix it.
> - Disable PF_RANDOMIZE for the binary. (Already doable)
> - Decrease randomization system-wide. (My patch lets you do this)
> - Decrease randomization for the binary to a point where it works.
> (Adding SELinux hooks and policy to my patch would allow this)
Which immediately makes your patch obsolete.
> Disabling randomization for the binary is much more fine-grained, but
> opens up that binary for attacks. Oracle breaks with high-order
> entropy; we can disable randomization on Oracle and keep high-order
> entropy, but now the database server is at risk. This isn't the
> greatest idea in the world either.
So fix Oracle. No need to invent serious infrastructure because Oracle
is broken.
> It appears to me that the best solution is per-policy, but we should
> leave even that up to the user. This means make a sane default--
> one
No. Current situation is okay as is. It does not need to be
configurable, and it should not be.
Per-architecture ammount of randomness would be welcome, I
believe. That will force Oracle to fix their code, but that's okay,
and you can use disable PF_RANDOMIZE for Oracle in meantime.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
