DevHeads.net

F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

<a href="https://fedoraproject.org/wiki/Changes/HardenedCompiler" title="https://fedoraproject.org/wiki/Changes/HardenedCompiler">https://fedoraproject.org/wiki/Changes/HardenedCompiler</a>

== Summary ==
By Default enable a few security hardening flags which are used with GCC.

== Owner ==
* Name: [[User:huzaifas|Huzaifa Sidhpurwala]]
* Email: <a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>
* Release notes owner: <a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>

== Detailed Description ==
Currently GCC does not enable any security hardening flags by default.
They have to be explicitly enabled by the developers one-by-one.
Ubuntu (<a href="https://wiki.ubuntu.com/ToolChain/CompilerFlags" title="https://wiki.ubuntu.com/ToolChain/CompilerFlags">https://wiki.ubuntu.com/ToolChain/CompilerFlags</a>) however
enables them and therefore has a hardened compiler by default. Each of
these options can be explicitly disabled if required by the developer
via a GCC command line flag. I am currently proposing the following
flags be enabled by default.

'''-Wformat -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O'''''

{| class="wikitable"
|-
! No !! Flag !! Use !! How to disable
|-
| 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make
sure that the arguments supplied have types appropriate to the format
string specified, and that the conversions specified in the format
string make sense. || -Wno-format
|-
| 2 || -Wformat-security || If -Wformat is specified, also warn about
uses of format functions that represent possible security problems.
|| -Wno-format should disable this as well
|-
| 3 || -fstack-protector-strong || Like -fstack-protector but includes
additional functions to be protected --- those that have local array
definitions, or have references to local frame addresses.
|| -fno-stack-protector
|}

== Benefit to Fedora ==
We provide better security both for our packages and for
applications/programs which users are building.

== Scope ==
* Proposal owners: Patch gcc to enable these options by default. Patch
should be very simple, since the compile/link code isnt actually
touched.
* Other developers: Developers need to ensure that Fedora package is
built and if any build failures they are corrected
* Release engineering: [https://pagure.io/releng/issue/8204 #8204]
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: Not needed for this change

== Upgrade/compatibility impact ==
None

== How To Test ==
Run "gcc -Q -v <foo.c>" to check if these flags are enabled by default

== User Experience ==
Fedora is more secure because the entire distribution is compiled with
the correct security technologies enabled. Developers dont have to
worry about enabling the right flags when they compile their
application in Fedora because the compiler has them enabled by
default.

== Dependencies ==
All packages will be rebuild with new GCC options.

== Contingency Plan ==
* Contingency mechanism: Roll back the GCC options and use the default ones.
* Contingency deadline: Beta Feeze
* Blocks release? No

Comments

Re: F31 System-Wide Change proposal: Enable Compiler Security ha

By Florian Weimer at 03/11/2019 - 14:18

* Ben Cotton:

--param=ssp-buffer-size=4 will not affect anything because
-fstack-protector-strong uses a completely different heuristic.

We can check using annocheck if there are packages missing hardening and
fix them. What's the current level of coverage we have?

Have the Red Hat Enterprise Linux 8 packaging changes been upstreamed?
We were aiming for nearly-complete coverage there.

-D_FORTIFY_SOURCE=2 by default needs patching of glibc because of the
pesky warning it prints without optimization.

What about PIE by defauld and non-lazy binding by default? These two
are probably the two hardest to get right with CFLAGS/LDFLAGS injection.
(PIE is the reason for the -specs= hack.)

PIE-by-default compilers are very common already, although there are
many StackOverflow questions from peopel who use them and follow older
training material.

Thanks,
Florian