Expanding the list of "Hardened Packages"
Miloslav Trmač
mitr at volny.cz
Thu Apr 11 16:40:07 UTC 2013
On Thu, Apr 11, 2013 at 6:32 PM, John Reiser <jreiser at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130411/7f5e6842/attachment.html>
More information about the devel
mailing list