From Fedora Project Wiki
(Explain the flag situation)
Line 83: Line 83:
 
For both hardened and non-hardened builds, it is possible to compile everything with <tt>-fpic</tt>.  This comes at a performance cost, but it can simplify injecting the flags into the build process.
 
For both hardened and non-hardened builds, it is possible to compile everything with <tt>-fpic</tt>.  This comes at a performance cost, but it can simplify injecting the flags into the build process.
  
Alternatively, you can set the <tt>_hardended_build</tt> RPM macro to 1This will enable additional GCC specs files (which are not related to RPM spec files), altering the compiler driver behavior in the following way:
+
Alternatively, you can rely on the RPM-provided compiler and linker flag settingsIn Fedora 23, this will enable additional GCC specs files (which are not related to RPM spec files), altering the compiler driver behavior in the following way:
  
 
* If there is no <tt>-fpic</tt>-style flag on the command line, the source file is compiled as if <tt>-fpie</tt> were specified.
 
* If there is no <tt>-fpic</tt>-style flag on the command line, the source file is compiled as if <tt>-fpie</tt> were specified.
Line 89: Line 89:
 
* <tt>-z now</tt> is always passed to the linker.
 
* <tt>-z now</tt> is always passed to the linker.
  
This happens by injection <tt>CFLAGS</tt>, <tt>CXXFLAGS</tt>, and <tt>LDFLAGS</tt> environment variables in the invocation of the <tt>%configure</tt> RPM macro.  Details are in the <tt>/usr/lib/rpm/redhat/macros</tt> file.
+
This happens by injection <tt>CFLAGS</tt>, <tt>CXXFLAGS</tt>, and <tt>LDFLAGS</tt> environment variables in the invocation of the <tt>%configure</tt> RPM macro.  Details are in the <tt>/usr/lib/rpm/redhat/macros</tt> file. (In previous Fedora releases, this only happened when the <tt>_hardended_build</tt> RPM macro was set to 1 in the spec file.)
  
 
In effect, this maps the non-hardening column to the hardening column in the table above.
 
In effect, this maps the non-hardening column to the hardening column in the table above.
 
* TODO: Check the <tt>g++</tt> situation.
 
  
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==

Revision as of 10:32, 13 March 2015

Harden all packages with position-independent code

Summary

Harden all packages with position-independent code to limit the damage from certain security vulnerabilities. You can compare the security by running the following as root:

  • yum install checksec
  • checksec --proc-all

Owner

  • Name: Till Maas | Moez Roy
  • Email: opensource@till.name | moez.roy@gmail.com
  • Release notes owner:

Current status

Detailed Description

Currently, the Packaging Guidelines allow maintainers to decide whether their packages use position-independent code (PIC). There are rules that say that a lot of packages should use PIC, but in reality a lot of packages do not use PIC even if they must. Also since a lot of packages if not all potentially process untrusted input, it makes sense for these packages to use PIC to enhance the security of Fedora. Therefore I propose to build all packages with PIC by changing RPM to use the appropriate flags by default.

Implementation (done): Change line 130 in redhat-rpm-config macros from #_hardened_build 0 to %_hardened_build 1


References:

Detailed Harden Flags Description

The following only deals with flags added by this proposal. It does not mention existing hardening flags such as the -fstack-protector-strong compiler flag or the -z relro linker flag.

This table shows the required compiler and linker flags with and without full ASLR support. The flags are described from the perspective of the gcc or g++ compiler driver, so linker flags (for ld) are prefixed with -Wl.

Non-hardening Hardening
Compile for static linking (nothing) -fpie
Link executable (nothing) -pie -Wl,-z,now
Compile for dynamic linking -fpic -fpic
Link shared object -shared -shared -Wl,-z,now

On some architectures, there are variant flags -fPIC and -fPIE that larger programs have to use, there is a performance cost associated with them. They should be used only if linking would fail otherwise.

The key change is that for PIE builds, compilation for static linking (such as object files which go into the main program, not a library) needs a flag, -fpie. But this flag must not be included when compiling for dynamic linking because the resulting object code is not compatible with that. To repeat, you should not specify both -fpic and -fpie on the same command line because this rarely has the intended effect.

For both hardened and non-hardened builds, it is possible to compile everything with -fpic. This comes at a performance cost, but it can simplify injecting the flags into the build process.

Alternatively, you can rely on the RPM-provided compiler and linker flag settings. In Fedora 23, this will enable additional GCC specs files (which are not related to RPM spec files), altering the compiler driver behavior in the following way:

  • If there is no -fpic-style flag on the command line, the source file is compiled as if -fpie were specified.
  • If there is no -shared flag on the command line, the program is linked with -pie.
  • -z now is always passed to the linker.

This happens by injection CFLAGS, CXXFLAGS, and LDFLAGS environment variables in the invocation of the %configure RPM macro. Details are in the /usr/lib/rpm/redhat/macros file. (In previous Fedora releases, this only happened when the _hardended_build RPM macro was set to 1 in the spec file.)

In effect, this maps the non-hardening column to the hardening column in the table above.

Benefit to Fedora

Packages in Fedora will be more secure than in other distributions or packages provided by upstream. Therefore our users less likely become victims of attacks. Fedora will use more state-of-the-art security mechanisms to fulfill its first and features foundations.

Scope

  • Proposal owners:

Help writing the new packaging guidelines.

  • Other developers:

Change the rpm macros to build packages by default with PIC/PIE flags (i.e. set _hardened_package to 1 by default). Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1192183

  • Release engineering:

Do a mass rebuild for all arch packages

  • Policies and guidelines:

Adjust the Packaging Guidelines to allow non-PIC packages only if the package is not working otherwise and require a tracker bug similar to packages not working on certain archs. Update the Guidelines to reflect the new defaults.

Upgrade/compatibility impact

This should not cause problems with upgrades.

How To Test

  1. Running checksec should always report only

Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH otherwise a tracking bug should exist for the respective packages. All packages need to be tested as usual for normal behaviour.

User Experience

Fedora users might notice less sucessful attacks on their systems.

Dependencies

The rpm macros for Fedora need to be adjusted. Prelink might be retired.

Contingency Plan

  • Contingency mechanism: Rebuild packages only that do not work because of this without PIC.
  • More Details: Rel-Eng will add '%undefine _hardened_build' to the top of the spec file for packages that fail to build.
  • Contingency deadline: beta freeze
  • Blocks release? No

Documentation

The current packaging guidelines can be consulted.


Release Notes

Fedora now hardens as much packages as possible with position-independent code to reduce the impact of certain potential security vulnerabilities.