通过纯粹的机会，我偶然发现了一篇文章，提到你可以用-pie -fPIE“启用”ASLR（或者更确切地说，让你的应用程序能够识别ASLR）。通常也会推荐-fstack-protector（尽管我很少看到它如何以及针对它保护的攻击类型的解释）。
是否有一系列有用的选项和解释如何提高安全性？
...
当你的应用程序使用大约30个不使用它们的库时，这些措施有多大用处？ ;）
答案 0 :(得分：6)
Hardened Gentoo使用这些标志：
CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2"
LDFLAGS="-Wl,-z,now -Wl,-z,relro"
与默认phoronix基准测试套件中优化的Gentoo linux（包括PaX / SElinux和其他测量，而不仅仅是CFLAGS）相比，我看到了大约5-10％的性能下降。
答案 1 :(得分：5)
Hardening page on the Debian wiki解释了至少可以在Linux上使用的最常见的那些。列表中缺少的是-D_FORTIFY_SOURCE = 2，-Wformat，-Wformat-security，以及动态加载器中的relro和现在的功能。
答案 2 :(得分：4)
至于你的最后一个问题：
当你的应用程序使用大约30个不使用它们的库时，这些措施有多大用处？ ;）
仅在主程序能够以随机地址加载时才需要PIE。 ASLR始终适用于共享库，因此无论您是使用一个共享库还是100个，PIE的好处都是相同的。
堆栈保护程序只会使用堆栈保护程序编译的代码受益，因此如果您的库中存在漏洞，那么仅在主程序中使用它将无济于事。
无论如何，我建议您不要将这些选项视为应用程序的一部分，而是整个系统集成的一部分。如果您在一个与不受信任的，潜在恶意数据接口的程序中使用30多个库（可能大多数在代码质量和安全性方面都是垃圾），那么建立您的库是个好主意。整个系统，带有堆栈保护器和其他安全加固选项。
但请记住，_FORTIFY_SOURCE的最高级别以及其他一些新安全选项可能会破坏合法，正确程序可能需要执行的有效内容，因此您可能需要分析它是否＆＃ 39;使用它们是安全的。其中一个选项（我忘记了哪个）使得它%n printf %n说明符的一个已知危险的东西不起作用，至少在某些情况下是这样。如果某个应用程序正在使用{{1}}来获取生成的字符串的偏移量，并且需要使用该偏移量以便稍后写入，并且该值未被填写，则该“潜在漏洞”本身就是一个潜在的漏洞...