User:Kevin/DRAFT When to use PIE compiler flags

This page is a DRAFT
This page is a draft, please don't follow it until it's no longer a draft

Introduction

PIE (Position Independent Executables) are binaries that are made entirely from position-independent code. This allows for address space layout randomization, increasing security and making some attacks much more difficult. In Fedora 16 and later there are macros to easily enable compiling a package with the compiler and linker flags needed for PIE.

Advantages

• Binaries are more difficult to attack/compromise.

Disadvantages

• You can no longer use prelink on your binaries, resulting in a slower startup time.

Compiler flags

Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build.

For C, C++, and Fortran code, the  %{optflags} macro contains these flags. Overriding these flags for performance optimizations (for instance, -O3 instead of -O2) is generally discouraged. If you can present benchmarks that show a significant speedup for this particular code, this could be revisited on a case-by-case basis. Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so must be documented in the specfile.

There are certain, security related flags that are commonly allowed. These flags may degrade performance slightly but the increased security can be worthwhile for some programs.

PIE

PIE adds security to executables by composing them entirely of position-independent code. Position-independent code (PIC) is machine instruction code that executes properly regardless of where in memory it resides. PIE allows Exec Shield to use address space layout randomization to prevent attackers from knowing where existing executable code is during a security attack using exploits that rely on knowing the offset of the executable code in the binary, such as return-to-libc attacks.

To use this in your spec, add:

%define _hardened_build 1

This adds -fPIC (if -fPIE is not already present) to the compiler flags, and adds -z now to the linker flags.

FESCo maintains a list of packages that MUST have PIE turned on. Other packages may enable the flags at the maintainer's discretion.

If your package meets the following critera you should consider enabling the PIE compiler flags:

• Your package is long running. This means it's likely to be started and keep running until the machine is rebooted, not start on demand and quit on idle.

• Your package has suid binaries, or binaries with capabilities.

• Your package runs as root.

• Your package accepts/processes untrusted input.

There are some notable disadvantages to enabling PIE that should be considered in making the decision:

• Some code does not compile with PIE (or does not function properly).

• You can not use prelink on PIE enabled binaries, resulting in a slower startup time.

references

http://en.wikipedia.org/wiki/Position-independent_code

https://fedorahosted.org/fesco/ticket/563

https://fedorahosted.org/fpc/ticket/93

http://wiki.debian.org/Hardening

https://wiki.ubuntu.com/Security/Features

https://wiki.ubuntu.com/Security/Features#Built_as_PIE