From Fedora Project Wiki
< Changes
(Hardening Flags Updates for Fedora 28) |
No edit summary |
||
| (15 intermediate revisions by 5 users not shown) | |||
| Line 21: | Line 21: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= Hardening Flags Updates for Fedora 28 | = Hardening Flags Updates for Fedora 28 = | ||
== Summary == | == Summary == | ||
| Line 29: | Line 29: | ||
* Name: [[User:fweimer| Florian Weimer]] | * Name: [[User:fweimer| Florian Weimer]] | ||
* Email: fweimer@redhat.com | * Email: fweimer@redhat.com | ||
* Release notes | * Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/92 #92] | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
| Line 41: | Line 41: | ||
* Targeted release: [[Releases/28 | Fedora 28]] | * Targeted release: [[Releases/28 | Fedora 28]] | ||
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | * Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1534527 #1534527] | ||
== Detailed Description == | == Detailed Description == | ||
* Compile all binaries with stack clash protection (<code>-fstack-clash-protection</code>). As a result, | * Compile all binaries with stack clash protection (<code>-fstack-clash-protection</code>). As a result, attempts to jump the stack guard (a requirement for stack clash attacks) will reliably result in a crash rather than giving the attacker control over stack/heap objects. | ||
* Enable C++ standard library hardening with <code>-D_GLIBCXX_ASSERTIONS</code>. This turns on cheap range checks for C++ arrays, vectors, and strings. | * Enable C++ standard library hardening with <code>-D_GLIBCXX_ASSERTIONS</code>. This turns on cheap range checks for C++ arrays, vectors, and strings. | ||
* Enable control flow protection on x86-64 using <code>-fcf-protection=full -mcet</code>. | * Enable control flow protection on x86-64 using <code>-fcf-protection=full -mcet</code>. | ||
* Enable | * Enable <code>.got.plt</code> isolation in binutils, to support a read-only GOT with lazy binding on systems which provide support for memory protection keys. | ||
* Use --enable-default-pie to ensure PIE support is enabled across all architectures. | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
| Line 55: | Line 56: | ||
== Scope == | == Scope == | ||
* Proposal owners: Propose changes to | * Proposal owners: Propose changes to <code>redhat-rpm-config</code> to implement the new flags. | ||
** [https://bugzilla.redhat.com/show_bug.cgi?id=1515865 <code>redhat-rpm-config</code>: Enable <code>-fstack-clash-protection</code>] | |||
* Other developers: The <code>redhat-rpm-config</code> changes need to be merged. For packages which bypass the RPM compiler flags injection mechanism, developers need to manually implement the new flags. | |||
* Release engineering: [https://pagure.io/releng/issue/7220 #7220] and [https://pagure.io/releng/issue/7249 #7249] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> | |||
* Release engineering: [https://pagure.io/releng/ | |||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
| Line 85: | Line 86: | ||
== Contingency Plan == | == Contingency Plan == | ||
* Contingency mechanism: Revert change to <code>redhat-rpm-config</code>. | * Contingency mechanism: Revert change to <code>redhat-rpm-config</code>, or make them specific to supported architectures only. | ||
** An ABI-compliant <code>-fstack-clash-protection</code> implementation has not yet been demonstrated for 32-bit ARM (armhfp). It may be necessary to disable the hardening there. | |||
* Contingency deadline: final mass rebuild | * Contingency deadline: final mass rebuild | ||
* Blocks release? no | * Blocks release? no | ||
| Line 94: | Line 96: | ||
* [https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html|<code>-fstack-clash-protection</code>] | * [https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html|<code>-fstack-clash-protection</code>] | ||
* [https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html|<code>_GLIBCXX_ASSERTIONS</code>] | * [https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html|<code>_GLIBCXX_ASSERTIONS</code>] | ||
* [https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf | * [https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf Control Flow Enforcement Technology] | ||
== Release Notes == | == Release Notes == | ||
| Line 104: | Line 106: | ||
* On x86-64, binaries have been built in a way that they will support Control Flow Enforcement Technology (CET) in the future. | * On x86-64, binaries have been built in a way that they will support Control Flow Enforcement Technology (CET) in the future. | ||
* On systems which support memory protection keys, lazy binding now uses a read-only GOT. | * On systems which support memory protection keys, lazy binding now uses a read-only GOT. | ||
* By default the toolchain generates PIE executables to further harden Fedora executables from attacks. | |||
[[Category: | [[Category:ChangeAcceptedF28]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Latest revision as of 14:52, 2 March 2018
Hardening Flags Updates for Fedora 28
Summary
This system-wide change covers changes to the hardening flags in Fedora 28.
Owner
- Name: Florian Weimer
- Email: fweimer@redhat.com
- Release notes ticket: #92
Current status
Detailed Description
- Compile all binaries with stack clash protection (
-fstack-clash-protection). As a result, attempts to jump the stack guard (a requirement for stack clash attacks) will reliably result in a crash rather than giving the attacker control over stack/heap objects. - Enable C++ standard library hardening with
-D_GLIBCXX_ASSERTIONS. This turns on cheap range checks for C++ arrays, vectors, and strings. - Enable control flow protection on x86-64 using
-fcf-protection=full -mcet. - Enable
.got.pltisolation in binutils, to support a read-only GOT with lazy binding on systems which provide support for memory protection keys. - Use --enable-default-pie to ensure PIE support is enabled across all architectures.
Benefit to Fedora
Fedora will benefit from additional security hardening provided by the GNU toolchain.
Scope
- Proposal owners: Propose changes to
redhat-rpm-configto implement the new flags. - Other developers: The
redhat-rpm-configchanges need to be merged. For packages which bypass the RPM compiler flags injection mechanism, developers need to manually implement the new flags.
- Policies and guidelines: N/A (not needed for this Change; covered by the existing Packaging Guidelines)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
The C++ standard library hardening may detect some invalid out-of-bounds access which have gone unnoticed before.
How To Test
Changes/Annobin will be used to track the implementation of the hardening flags.
User Experience
There will not be any user-visible differences.
Dependencies
Testing depends on Changes/Annobin.
Contingency Plan
- Contingency mechanism: Revert change to
redhat-rpm-config, or make them specific to supported architectures only.- An ABI-compliant
-fstack-clash-protectionimplementation has not yet been demonstrated for 32-bit ARM (armhfp). It may be necessary to disable the hardening there.
- An ABI-compliant
- Contingency deadline: final mass rebuild
- Blocks release? no
- Blocks product? N/A
Documentation
Release Notes
Fedora 28 has been built with updated hardening flags, as provided by the GNU toolchain. Compared to previous releases, the following changes have been made to the way programs are built:
- Stack clash protection is enabled.
- Lightweight assertions have been switched on in the C++ standard run-time library.
- On x86-64, binaries have been built in a way that they will support Control Flow Enforcement Technology (CET) in the future.
- On systems which support memory protection keys, lazy binding now uses a read-only GOT.
- By default the toolchain generates PIE executables to further harden Fedora executables from attacks.