F22 System Wide Change: Harden all packages with position-independent code

[Reindl Harald]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150107/4f1d1857/attachment.sig>