Exec-shield and memory randomization

[Dave Roberts]

On Sun, 2005-07-31 at 19:46 +0200, Arjan van de Ven wrote:
> > . That it, they seem independent, but most of the
> > documentation on exec-shield I have seen seems to suggest that turning
> > off exec-shield should turn off just about everything and leave you with
> > a pretty standard system, ala the pre-exec-shield days. Is that no
> > longer true?
> 
> well.. randomisation is now merged upstream....

I'm not sure I understand. So that means "yes, they are now
independent" ?

So assuming that's the case, what does the kernel look for in
determining whether to turn of randomization on a per-binary basis? In
reading some older materials (like last year's Security Enhancements in
Red Hat Enterprise Linux paper by Drepper), it looked like the presence
of an explicitly executable stack segment in the ELF binary would turn
off all the various exec-shield enhancements, including randomization.
I'm guessing that this is still true for exec-shield, but does anything
now control randomization?

Running readelf and looking at the stack segment shows:

[dave at linux ~]$ readelf -l /usr/bin/sbcl | fgrep STACK
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

which as I understood it means that the stack is being marked as
executable (the "E" in the "RWE" field, right?).

So shouldn't this binary not be getting randomized memory addresses in
any case?

In any case, sorry to be persistent about this stuff. I have no desire
to be a pest. If you can point me to any up-to-date docs on this stuff,
I'd be happy to RTFM. I have been searching for anything I can get my
hands on but have been generally unsuccessful. Everything I read seems
to predate the change of randomization being merged upstream and so
short of reading the patches all myself (which comes next, I suppose), I
haven't found anything particular authoritative about how this works. An
email from yourself would be worth its weight in gold (at least if you
printed it out ;-).

-- 
Dave Roberts <ldave at droberts.com>