Add security hardening for 4.0.1? (was: Introducing security hardening features for Lenny)

[Armin Berres]

I guess there will be a long discussion on -devel, here are some short 
hints from MaxCoder (taken from #debian-qt-kde):

.:23:23:37:.     MadCoder| SSP, FORTIFY_SOURCES, and PIE are critical performance wise
.:23:23:52:.   mukidohime| PIE is brutal to performance, though, right?
.:23:23:55:.     MadCoder| SSP is particularily expensive for an application that performs a lot of 'calls'
.:23:24:04:.      trigger| hm, bad
.:23:24:20:.     MadCoder| and PIE is very expensive on registers starved archs like … the not very used x86
.:23:24:31:.     MadCoder| so don't get _too_ excited either
.:23:24:41:.     MadCoder| -D_FORTIFY_SOURCES=1 is a good idea though
.:23:24:55:.     MadCoder| it generates no runtime checks, and detectes a handful of important mistakes
.:23:25:33:.      trigger| so -D_FORTIFY_SOURCES=1 and nothing else? or should one consider SSP?
.:23:26:41:.     MadCoder| well, -pie is a very bad idea IMNSHO
.:23:26:46:.     MadCoder| the rest depends on the application
.:23:27:04:.     MadCoder| I just say, don't get _too_ excited, most of the proposed flags/features/... have an inherent cost
.:23:27:06:.   mukidohime| I guess it would require some kind of serious profiling.
.:23:27:37:.     MadCoder| SSP is a technique that puts a canary (a random value) on the stack before (or after I never remember, I suppose it's arch dependent anyways) on
                           the stack
.:23:27:50:.     MadCoder| and just before you RET from the call, it checks if the canary is still there
.:23:28:21:.     MadCoder| it detects stack smashing based on the fact that if the attacker cannot guess the canary, he'll probably overwrite it
.:23:28:29:.     MadCoder| it's quite effective for a broad range of attacks
.:23:28:37:.      trigger| i see
.:23:28:45:.     MadCoder| though, each _RET_ (and there is usually one per call) costs an additionnal check
.:23:29:19:.     MadCoder| so it's a performance killer for anything that does CPU-bound operations, and is coded using lots of functions
.:23:29:39:.     MadCoder| _FORTIFY_SOURCES=2 is on the same vein
.:23:29:59:.     MadCoder| it replaces some "dangerous" string operations with functions that try to check boundaries some way or the other
.:23:30:05:.     MadCoder| I don't really know how, I just know it costs
.:23:30:20:.     MadCoder| and well, when it's strcpy or strcat, I don't care, people using those should be shot
.:23:30:25:.     MadCoder| but it checks memcpy and memmove too
.:23:30:31:.     MadCoder| and _THAT_ sucks
.:23:30:45:.      trigger| who needs memcpy? ;)
.:23:30:57:.     MadCoder| -fPIE and -pie have the same issue as shared libraries do
.:23:31:05:.   mukidohime| So, it's trading stack smashing for performance smashing?
.:23:31:11:.     MadCoder| all is rellocatable, hence every jump will be done based on an offset
.:23:31:32:.     MadCoder| and x86 hasn't all the relative opcodes, hence it blocks one register to store the offset in it
.:23:31:59:.     MadCoder| other archs are less impacted afaict (like amd64 that has all the necessary opcodes _and_ has more registers)
.:23:32:19:.     MadCoder| so it's not really obvious to me that we should make those 3 options default everywhere
.:23:32:36:.     MadCoder| so don't jump on horses _yet_ :)
.:23:32:50:.   mukidohime| PIE is definitely only for a few specific uses.
.:23:33:06:.      trigger| so -D_FORTIFY_SOURCES=1 and waiting FTW :)
.:23:33:30:.   mukidohime| SSP... that would require some profiling to check the performance hit.
.:23:34:17:.     MadCoder| well, SSP is probably not a problem for many desktop applications
.:23:34:35:.     MadCoder| though, multimedia guys won't like it, whereas it's the kind of applications that are the most vulnerable
.:23:34:54:.   mukidohime| Yeah, I think they'd much rather live fast and loose though.
.:23:34:56:.     MadCoder| so well, all that talk was just to say, don't hurry, wait for the discussion that will probably come