> Unfortunately, the people from Ubuntu don't care much about security.
I respect your right to have an opinion, but please never say that in the presence of people from Ubuntu Security Team!

I've run checksec.sh on both my Luna and Freya systems and here's what I can tell wrt its complaints:

== No canary found ==
Most canary absence reports are sort-of false positives. Ubuntu defaults to "-fstack-protector" compiler flag and checksec.sh seems to only detect canaries in things compiled with "-fstack-protector-all". 

Stack canaries are arguably not particularly useful in a dominant market-share distro with prebuilt packages, since the canary values for > 60% of systems are known to the attacker and on at about 40% systems they're the same, just because Ubuntu LTS releases are so predominant. 

However, there is room for improvement here: instead of "-fstack-protector" we could use "-fstack-protector-strong" that protects more functions than regular "-fstack-protector". 

It is not practical to implement en masse on elementary OS, since we cannot possibly rebuilt the entire Ubuntu archive with these flags. Besides, security improvements should not be exclusive to elementary OS - we'd very much like for Ubuntu and derivatives to use that as well, especially on servers where security is arguably more critical.

So I suggest talking to Ubuntu Security Team about it. As in, drop in to #ubuntu-security on FreeNode and ask why they're not using "-fstack-protector-strong" yet and if there are any plans to switch to it. 
If needed, more comms channels are listed here: https://wiki.ubuntu.com/SecurityTeam/GettingInvolved

I will, however, investigate using "-fstack-protector-strong" explicitly in our most critical packages, e.g. Midori. But I *strongly* suggest you to talk it through with Ubuntu Security Team. Talking them into it would be best for everyone.

== Partial RELRO ==

Similar story here. There's at least one argument against full RELRO - "it may increase startup time" because the dynamic linker has to perform the relocations at startup. We've actually investigated linker optimizations and it turned out that they're rather pointless - the time spent in the linker is negligible compared to the full startup time, especially in GUI applications which are just blocked waiting for replies from X server for a damn long time.

The author of a (now obsolete) linker optimization had detailed a pretty good way of measuring startup time wrt linking overhead, see http://gcc.gnu.org/ml/gcc/2001-05/msg01670.html
If you could run these tests on several programs with varying number of libraries and show that full RELRO isn't much more costly than partial RELRO, that'd be an actionable result that we could show to Ubuntu Security Team and say "Hey guys you should totally do this!"

== No PIE ==

I have to admit I don't really understand what security benefits PIE brings, aside of "it has something to do with ASLR". I'd appreciate a link to an explaination.
It seems that it's not enabled by default since not all programs can successfully compile with it, so it's enabled manually on a per-package basis. I'd be glad to add PIE as default to our packages, most likely on the build system level so other distros benefit from it too, but only if anyone explains why it's a good idea in the first place.

JFYI the script does not test for fortified functions in running processes (-D_FORTIFY_SOURCE=2), which is a pity. It also hasn't been updated since 2011...

P.S. Any news on AppArmor profile blocking shutdown in DNSCrypt-proxy? If not, I'll just drop the AppArmor profile from the package, since DNSCrypt chroots anyway.