From Fedora Project Wiki
(→‎Owner: If someone wants to back this up or help, please add yourself to the proposal owners.)
m (better readability)
 
(46 intermediate revisions by 8 users not shown)
Line 1: Line 1:
= Change Proposal Name <!-- The name of your change proposal --> =
= Harden All Packages <!-- The name of your change proposal --> =
Harden all packages with position-independent code
== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->


Harden all packages with position-independent code to limit the damage from certain security vulnerabilities.
In Fedora 22 and before, it was up to the package maintainer to add <code>%global _hardened_build 1</code> to their spec file to ensure their program was hardened. Beginning with Fedora 23 this will now become the defaults for all packages. You can compare the security by running the following as root:
 
* <code>dnf install checksec</code>
* <code>checksec --proc-all</code>
 
To see the mitigations in the libraries that a process is using, find the process id from the previous command (for example 123):
 
* <code>checksec --proc-libs 123</code>


== Owner ==
== Owner ==
* Name: [[User:Till|Till Maas]] | [[User:Moezroy|Moez Roy]]
* Name: [[User:Till|Till Maas]] | [[User:Moezroy|Moez Roy]] | [[User:Ajax|Adam Jackson]] | [[User:Fweimer|Florian Weimer]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: opensource@till.name | moez.roy@gmail.com
* Email: opensource@till.name | moez.roy@gmail.com | ajax@redhat.com | fweimer@redhat.com
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- * Release notes owner: To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:Ajax|Adam Jackson]] <ajax@redhat.com>
-->
 
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
* Product:
* Product:
Line 20: Line 25:


== Current status ==
== Current status ==
* Targeted release: [[Releases/22 | Fedora 22 ]]  
* Targeted release: <strike>[[Releases/22 | Fedora 22 ]] </strike> [[Releases/23 | Fedora 23 ]]
* Last updated: 2014-12-13
* Last updated: 2015-02-12
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Bugzilla states meaning as usual:
Bugzilla states meaning as usual:
Line 30: Line 35:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracking bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1215939 #1215939]
* Build failures tracking bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1199775 #1199775]


== Detailed Description ==
== Detailed Description ==
Currently, the [[Packaging:Guidelines#PIE|Packaging Guidelines]] allow
Currently, the [[Packaging:Guidelines#PIE|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 packags 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.
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 [https://pkgs.fedoraproject.org/cgit/redhat-rpm-config.git/tree/macros redhat-rpm-config macros] from <nowiki>#_hardened_build 0</nowiki> to <nowiki>%_hardened_build 1</nowiki>
 


References:
References:
* https://fedorahosted.org/fesco/ticket/1384
* https://fedorahosted.org/fesco/ticket/1113 (older attempt with many references)
* https://fedorahosted.org/rel-eng/ticket/6049
* https://fedorahosted.org/rel-eng/ticket/6049
* There should be several mails about this on the devel list
* There should be several mails about this on the devel list
* [https://bugzilla.redhat.com/show_bug.cgi?id=1199775 Build failures tracker bug]
=== Detailed Harden Flags Description ===
The following only deals with flags added by this proposal.  It does not mention existing hardening flags such as the <tt>-fstack-protector-strong</tt> compiler flag or the <tt>-z relro</tt> 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 <tt>gcc</tt> or <tt>g++</tt> compiler driver, so linker flags (for <tt>ld</tt>) are prefixed with <tt>-Wl</tt>.
{|class="wikitable"
|
|'''Non-hardening'''
|'''Hardening'''
|-
|'''Compile for static linking'''
|(nothing)
|<tt>-fPIE</tt>
|-
|'''Link executable'''
|(nothing)
|<tt>-pie -Wl,-z,now</tt>
|-
|-
|'''Compile for dynamic linking'''
|<tt>-fPIC</tt>
|<tt>-fPIC</tt>
|-
|'''Link shared object'''
|<tt>-shared</tt>
|<tt>-shared -Wl,-z,now</tt>
|}
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 the flag <tt>-fPIE</tt>.  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 <tt>-fpic</tt> and <tt>-fpie</tt> 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 <tt>-fPIC -pie</tt>.  This 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 <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>-shared</tt> flag on the command line, the program is linked with <tt>-pie</tt>.
* <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.  (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.
[https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00445.html Copy relocations support in GCC 5 and binutils 2.26] makes the performance on x86_64 of PIE literally zero for many programs.


== 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:
redhat-hardened-cc1
Change the rpm macros to build packages by default with PIC/PIE flags (i.e. set _hardened_package to 1 by default).
*cc1_options:
+ %{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}


* Release engineering:
--------------------------------------------------
Do a mass rebuild for all arch packages


* Policies and guidelines:
redhat-hardened-ld
Adjust the Packaging Guidelines to allow non-PIC packages only if the package is not working otherwise and require a tracker bug similiar to packages not working on certain archs. Update the Guidlines to reflect the new defaults.
*self_spec:
+ %{!shared:-pie}
*link:
+ -z now


== Upgrade/compatibility impact ==
----------------------------------------------------
This should not cause problems with upgrades.


== How To Test ==
== How To Test ==
Line 76: Line 135:
<code>Full RELRO      Canary found      NX enabled    PIE enabled    No RPATH  No RUNPATH</code>
<code>Full RELRO      Canary found      NX enabled    PIE enabled    No RPATH  No RUNPATH</code>
otherwise a tracking bug should exist for the respective packages. All packages need to be tested as usual for normal behaviour.
otherwise a tracking bug should exist for the respective packages. All packages need to be tested as usual for normal behaviour.
=== Troubleshooting steps for package maintainers ===
1. Add <code>%global _hardened_build 1</code> and build your package against F21. As F21 uses GCC 4.9.2, older binutils, older glibc etc. you will be able to identify whether the build failure is caused by GCC5, the newer binutils, the new glibc etc..
2. If you get linker errors, you can try disabling <code>-z now</code> by putting the following under the <code>%build</code> section of your spec file:
CFLAGS="$RPM_OPT_FLAGS -Wl,-z,lazy"
CXXFLAGS="$RPM_OPT_FLAGS -Wl,-z,lazy"
export CFLAGS
export CXXFLAGS
3a. Check whether it builds successfully if you disable the hardening change:
%undefine _hardened_build
3b. Enable only PIE manually for your package:
CFLAGS="$RPM_OPT_FLAGS -fPIC -pie"
CXXFLAGS="$RPM_OPT_FLAGS -fPIC -pie"
export CFLAGS
export CXXFLAGS
3c. Enable only -z now manually for your package:
CFLAGS="$RPM_OPT_FLAGS -Wl,-z,relro -Wl,-z,now"
CXXFLAGS="$RPM_OPT_FLAGS -Wl,-z,relro -Wl,-z,now"
export CFLAGS
export CXXFLAGS
3d. Enable 3b and 3c above manually for your package:
CFLAGS="$RPM_OPT_FLAGS -fPIC -pie -Wl,-z,relro -Wl,-z,now"
CXXFLAGS="$RPM_OPT_FLAGS -fPIC -pie -Wl,-z,relro -Wl,-z,now"
export CFLAGS
export CXXFLAGS
== 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.


== User Experience ==
== User Experience ==
Line 86: Line 206:


== Contingency Plan ==
== Contingency Plan ==
* Contingency mechanism: Rebuild packages that do not work because of this without PIC. If there are too many packaged, do a mass rebuild again without PIC for all arch packages.
* Contingency mechanism: Package maintainers should refer to the section '''''Troubleshooting steps for package maintainers''''' above if they don't want their FTBFS packages retired.
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: If no mass rebuild is needed, indidual packages can be rebuilt at any time.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks release? No


Line 102: Line 222:
-->
-->


Fedora now hardens as much packages as possible with position-independent code to reduce the impact of certain potential security vulnerabilities.
Fedora now hardens as many packages as possible with position-independent code (ASLR) and FULL RELRO to reduce the impact of certain potential security vulnerabilities.


[[Category:ChangeReadyForWrangler]]
[[Category:ChangeAcceptedF23]]
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->  
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->  
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->


[[Category:SystemWideChange]]
[[Category:SystemWideChange]]

Latest revision as of 08:50, 9 January 2019

Harden All Packages

Summary

In Fedora 22 and before, it was up to the package maintainer to add %global _hardened_build 1 to their spec file to ensure their program was hardened. Beginning with Fedora 23 this will now become the defaults for all packages. You can compare the security by running the following as root:

  • dnf install checksec
  • checksec --proc-all

To see the mitigations in the libraries that a process is using, find the process id from the previous command (for example 123):

  • checksec --proc-libs 123

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


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 the 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 -pie. This 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.

Copy relocations support in GCC 5 and binutils 2.26 makes the performance on x86_64 of PIE literally zero for many programs.



redhat-hardened-cc1

*cc1_options:
+ %{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}

redhat-hardened-ld

*self_spec:
+ %{!shared:-pie}

*link:
+ -z now

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.


Troubleshooting steps for package maintainers

1. Add %global _hardened_build 1 and build your package against F21. As F21 uses GCC 4.9.2, older binutils, older glibc etc. you will be able to identify whether the build failure is caused by GCC5, the newer binutils, the new glibc etc..

2. If you get linker errors, you can try disabling -z now by putting the following under the %build section of your spec file:

CFLAGS="$RPM_OPT_FLAGS -Wl,-z,lazy"
CXXFLAGS="$RPM_OPT_FLAGS -Wl,-z,lazy"

export CFLAGS
export CXXFLAGS

3a. Check whether it builds successfully if you disable the hardening change:

%undefine _hardened_build

3b. Enable only PIE manually for your package:

CFLAGS="$RPM_OPT_FLAGS -fPIC -pie"
CXXFLAGS="$RPM_OPT_FLAGS -fPIC -pie"

export CFLAGS
export CXXFLAGS

3c. Enable only -z now manually for your package:

CFLAGS="$RPM_OPT_FLAGS -Wl,-z,relro -Wl,-z,now"
CXXFLAGS="$RPM_OPT_FLAGS -Wl,-z,relro -Wl,-z,now"

export CFLAGS
export CXXFLAGS

3d. Enable 3b and 3c above manually for your package:

CFLAGS="$RPM_OPT_FLAGS -fPIC -pie -Wl,-z,relro -Wl,-z,now"
CXXFLAGS="$RPM_OPT_FLAGS -fPIC -pie -Wl,-z,relro -Wl,-z,now"

export CFLAGS
export CXXFLAGS


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.

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: Package maintainers should refer to the section Troubleshooting steps for package maintainers above if they don't want their FTBFS packages retired.
  • Contingency deadline: beta freeze
  • Blocks release? No

Documentation

The current packaging guidelines can be consulted.


Release Notes

Fedora now hardens as many packages as possible with position-independent code (ASLR) and FULL RELRO to reduce the impact of certain potential security vulnerabilities.