[PATCH] Security hardening compiler and linker flags
Hi All The attached patch adds security hardening compiler and linker flags. These flags are only applied if --enable-secflags is on, and I've made --enable-secflags on by default. I totally understand if the maintainers may prefer for it to be off by default, at least initially. Here is a brief explanation/justification of each of the flags added by this patch. Compiler flags: -Wformat -Wformat-security -Werror=format-security: Protection against format string vulnerabilities at compile time, no impact to the compiled binaries. -fPIE: Build position independent executable (PIE) binaries. Enables a form of address space layout randomization (ASLR), which makes exploitation of memory corruption vulnerabilities significantly more difficult. This does incur a small performance cost, but this is minimal and I believe an acceptable price to pay for the protection PIE provides. For more details on the performance cost, see [0]. -fstack-protector-strong: Stack-smashing protection at runtime, thwarting many buffer overflow exploits. This does incur a small performance cost. -fstack-protector-strong is designed to incur a minimal performance cost, compared to the more comprehensive -fstack-protector-all. -D_FORTIFY_SOURCE=2: Protection against static sized buffer overflows at compile time, no impact to compiled binaries. Linker flags: -fPIE -pie: To enable PIE as noted above. -Wl,-z,relro: Prevents some memory corruption exploits that overwrite the global offset table (GOT). For more details see [1]. -Wl,-z,now: Part of GOT overwrite protection. Can incur an extremely minimal performance hit at startup time as symbols are resolved. -Wl,-z,noexecstack: Prevents some memory corruption exploits by marking the stack as non-executable. Not all of these flags are available on some architectures and processors, but they should be automatically omitted from the configure script if not supported. Thanks David [0] https://securityblog.redhat.com/2012/12/12/position-independent-executable-p... [1] https://isisblogs.poly.edu/2011/06/01/relro-relocation-read-only/
On Feb 27, David Jorm <djorm@corp.iixpeering.net> wrote:
The attached patch adds security hardening compiler and linker flags. These flags are only applied if --enable-secflags is on, and I've made --enable-secflags on by default. I totally understand if the maintainers may prefer for it to be off by default, at least initially. The warnings are OK, but while the hardening options actually match what Debian uses, distributions tipically want to explicitly set them themselves using the defaults of their own build infrastructure (because in the future they may want to do mass rebuilds with different flags).
-- ciao, Marco
On 02/27/2015 08:55 PM, Marco d'Itri wrote:
On Feb 27, David Jorm <djorm@corp.iixpeering.net> wrote:
The attached patch adds security hardening compiler and linker flags. These flags are only applied if --enable-secflags is on, and I've made --enable-secflags on by default. I totally understand if the maintainers may prefer for it to be off by default, at least initially. The warnings are OK, but while the hardening options actually match what Debian uses, distributions tipically want to explicitly set them themselves using the defaults of their own build infrastructure (because in the future they may want to do mass rebuilds with different flags).
Thanks for the feedback, Marco. I was thinking that distributions could override these flags by setting --enable-secflags off if they wanted to. If that is insufficient, then I would have no problem re-spinning the patch to set --enable-secflags off by default. Thanks David
David Jorm <djorm@corp.iixpeering.net> schrieb am Mi., 04.03.2015, 8:54: On 02/27/2015 08:55 PM, Marco d'Itri wrote:
On Feb 27, David Jorm <djorm@corp.iixpeering.net> wrote:
The attached patch adds security hardening compiler and linker flags. These flags are only applied if --enable-secflags is on, and I've made --enable-secflags on by default. I totally understand if the maintainers may prefer for it to be off by default, at least initially. The warnings are OK, but while the hardening options actually match what Debian uses, distributions tipically want to explicitly set them themselves using the defaults of their own build infrastructure (because in the future they may want to do mass rebuilds with different flags).
Thanks for the feedback, Marco. I was thinking that distributions could override these flags by setting --enable-secflags off if they wanted to. If that is insufficient, then I would have no problem re-spinning the patch to set --enable-secflags off by default. +1 Flags should be available but disabled by default at this state, imho, ymmv Thx for the patch David! Rgds, Stefan
On 03/06/2015 02:13 AM, Stefan Jakob wrote:
David Jorm <djorm@corp.iixpeering.net <mailto:djorm@corp.iixpeering.net>> schrieb am Mi., 04.03.2015, 8:54:
On 02/27/2015 08:55 PM, Marco d'Itri wrote: > On Feb 27, David Jorm <djorm@corp.iixpeering.net <mailto:djorm@corp.iixpeering.net>> wrote: > >> The attached patch adds security hardening compiler and linker flags. These >> flags are only applied if --enable-secflags is on, and I've made >> --enable-secflags on by default. I totally understand if the maintainers may >> prefer for it to be off by default, at least initially. > The warnings are OK, but while the hardening options actually match what > Debian uses, distributions tipically want to explicitly set them > themselves using the defaults of their own build infrastructure (because > in the future they may want to do mass rebuilds with different flags). >
Thanks for the feedback, Marco. I was thinking that distributions could override these flags by setting --enable-secflags off if they wanted to. If that is insufficient, then I would have no problem re-spinning the patch to set --enable-secflags off by default.
+1
Flags should be available but disabled by default at this state, imho, ymmv
Thx for the patch David!
Rgds, Stefan
Thanks Stefan - a respun patch with enable-secflags disabled by default is attached. David
participants (3)
-
David Jorm -
md＠Linux.IT -
Stefan Jakob