On Thu, Apr 11, 2013 at 6:32 PM, John Reiser <jreiser@bitwagon.com> wrote:
On 04/11/2013 08:19 AM, Miloslav Trmač wrote:
> (I'll call "mutating ASLR" a setup where the addresses change frequently,
> and "static ASLR" a setup where the addresses change only sometimes
> but differ between systems.)
>
> * Servers that accept outside connections definitely should have mutating ASLR
> (attackers can make millions of connection attempts and outguess static ASLR).
> So PIE and prelink unused or ineffective (== current policy).

What does it mean "So PIE and prelink unused or ineffective"?
That phrase lacks a verb.

Sorry. "So, let's keep the current policy: a) PIE enabled, b) prelink unused/ineffective for these executables".  It's not that prelink is ineffective against attackers, it's that as currently implemented, prelink does nothing when the executable is a PIE, so prelink does not disrupt "mutating ASLR".
 
A process that is invoked by xinetd in response to a particular packet,
and which terminates after serving only one logical connection, and whose
executable is built using "gcc -pie -FPIE, and not pre-inked,
then operates with short-lived, high-frequency, mutating ASLR.
That's one case of a "server" process invoked by xinetd.

Which of the major and frequently deployed servers actually use xinetd as their execution method?  Yes, xinetd is there; AFAIK it's by far not the common case; we usually have a separate long-running daemon (perhaps forking a child for each connection) instead.
 
If "server" is a whole system which lasts at least one day (tens or hundreds
of thousands of processes, or more) then "all executables -pie and -fPIE;
and no prelink" is a highest-frequency mutating ASLR.  It also has the
highest direct cost for performing all that randomized relocation.
 
Again, with PIE, prelink currently does nothing, so prelink/no prelink does not currently make a difference in this case.
     Mirek