Am 07.01.2015 um 23:04 schrieb Till Maas:
On Wed, Jan 07, 2015 at 08:30:03AM -0500, Josh Boyer wrote:
> We just went over something very much like this for x86_64 packages
> with FESCo ticket 1113:
>
>
https://fedorahosted.org/fesco/ticket/1113
>
> Could you perhaps review that and elaborate on the differences between
> that proposal and this one if there are any? Additionally, could you
> cover any of the concerns listed there that apply to this proposal?
I proposed to make it the default for all archs and not only x86_64.
From what I understand, the only reason it was not accepted is because
it was felt that the performance penalty is not worth the security gains
from this. I do not have objective numbers about how many exploits
that happened could be prevented with PIE and how many effort it took to
clean up after exploits compared to how much the performance penalty for
PIE costs.
in doubt a successful exploit does that much damage that you no longer
bother about some percent of performance and i really don't understand
all that performance discussions
i built *all* server packages running on our Fedora machines *long
before* "-fstack-protector-strong" became available with
"-fstack-protector-all" and i really care about every piece of
performance but not for the price of lower security
yes i maintain all my apache, postfix, dovecot, mysql, php and what not
packages in a own repo with maximized security options for 7 years now
and any tool not in the Fedora repos get a hardened build too
*but* i do not care about 5% performance because the time, money and
reputation impact caused by a successful exploit destroying and leaking
user data justifies to protect with all available technology and in
doubt if you need the 5% performance it justifies just go out and buy a
faster machine
yes, i talk about servers - because on a workstation it *really* don't
matter if LibreOffice the first time of a day starts a second longer
except for beenchmarking as digital p*** enlargement
However, the experts that I talked about this think the
protection is worth it. I was also told that there were exploits where
PIE helped to mitigate them.
i asked after Shellshock and reading that one of the issues would have
been mitigated on teh security list and referred to the 20 month old tickt
Nevertheless, nevertheless, thank you for
the ticket link, it contains a lot of interesting information. However
it is said that even though the packaging guidelines were mentioned
there, they were kept in an unclear/contradictory state. But this is
also a new data point, even though it was highlighted more 20 months ago
to FeSCo, there are still a lot of packages violating the Guideline
i filed *countless* bugreports for packages violating this in the past 2
years, many of them got fixed in the meantime
the main problem is "long running" - look how many prcoesses are started
on a ordinary desktop setup on-demand and than run forever and you get a
picture
frankly, even the browser, mailprogramm, messenger and so on are in fact
*long running* even if they are not servcices because most users start
them and have them running until logout, often over days
and guess what - all of this apps are processing untrsuted data from the
network, at the end of the day LibreOffice does too - just open a
attachment from a email and hit a unfixed security bug
which shows that the current process does not really work. And if PIE
is
not really considered to worth it, the guidelines should be adjusted to
reflect this. Currently it does not seem to be the case that most/all
packages that should be using PIE do not use it because maintainer
actively decided against it, but just because it is not the default. The
criteria for this is:
| Your package accepts/processes untrusted input.
This seems to be about every package that I use, because I most if not
all tools process untrusted data from the Internet
that's the point - in doubt even cat/grep prcoeed untrusted input from
the web by watch a simple logfile, there where even exploits
http://httpd.apache.org/security/vulnerabilities_22.html
mod_rewrite does not filter terminal escape sequences from logs, which
could make it easier for attackers to insert those sequences into
terminal emulators containing vulnerabilities related to escape sequences.
*every* application at the end of the day is at risk to proceed
untrsuted input from the web - and if it is only because it has to deal
with some download from the internt, in that context it don't matter if
it is long running or not