From Fedora Project Wiki

< Changes
Revision as of 10:08, 22 November 2024 by Asosedkin (talk | contribs) (punctuation changes)

Remove fips-mode-setup

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Remove the fips-mode-setup command provided by the crypto-policies package. The functionality it currently performs will be partially removed, partially replaced by automation.

Owner

  • Name: Clemens Lang
  • Email: cllang@redhat.com

Current status

  • Targeted release: Fedora Linux 42
  • Last updated: 2024-11-22
  • [Announced]
  • [<will be assigned by the Wrangler> Discussion thread]
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

fips-mode-setup in the crypto-policies package is currently used to switch Fedora systems into FIPS mode. FIPS mode is designed to change cryptographic components in Fedora (the kernel's crypto API, OpenSSL, NSS, GnuTLS, and libgcrypt) to comply with the United States Federal Information Processing Standards requirements for cryptographic modules, better known as FIPS 140.

We propose removing this utility. Instead, systems should be placed into FIPS mode using one of the following methods:

  • Pass fips=1 on the kernel command line of the Anaconda installer (i.e., install in FIPS mode)
  • Use the osbuild-composer image build functionality with the 
    [customizations]\n fips=true
    customization to build an image in FIPS mode
  • Use bootc as documented at https://gitlab.com/fedora/bootc/examples/-/tree/main/fips

Switching to FIPS mode after installation will be explicitly unsupported, see below for the rationale. Switching out of FIPS mode without reinstalling will be equally unsupported, since it does not make sense from a compliance point of view.


Context information on FIPS

For compliance with these standards, the cryptographic modules must be submitted to the Cryptographic Module Validation Program run by the US National Institute of Standards and Technology. Such certifications are lengthy efforts involving a company accredited to perform review and testing before submission, the so-called Cryptographic and Security Testing Laboratories (CSTLs). It takes upwards of a year to receive a certification, and costs a mid five-figure sum per CPU architecture to do this. Due to lack of funding and the fast pace of Fedora, Fedora's modules are not submitted. As a consequence, FIPS mode on Fedora is useful for testing only. Several distributions downstream of Fedora (RHEL, AlmaLinux, Oracle Linux, Amazon Linux), perform their own FIPS validations.

Occasionally, users think that enabling FIPS mode improves security. While running in FIPS mode does enable some additional checks and disables some older algorithms, we see FIPS mode as a compliance tool, not as a security tool. In some situations, enabling FIPS mode actually decreases security: for example, LUKS disk encryption normally uses the modern GPU-resistant Argon2 key derivation function, but because it is not FIPS-approved, it falls back to the older and generally considered weaker PBKDF2 in FIPS mode. FIPS mode also does not allow the use of Curve25519 for key exchange (used by default in TLS 1.3), or the ChaCha20-Poly1305 authenticated encryption algorithm (again, used in TLS 1.3) both of which are considered modern and good. We do not recommend running FIPS mode to "improve security". A well-configured crypto policy is a much better tool to limit the use of legacy algorithms without the side effect of disabling newer non-US-specified algorithms.

Why remove fips-mode-setup?

To correctly switch a system to FIPS mode, multiple knobs need to be adjusted:

  • The system-wide cryptographic policy needs to be FIPS or based on it
  • The fips dracut initramfs module needs to be enabled to run an integrity test (a FIPS 140 requirement) on the kernel image, followed by re-generating the initramfs
  • The kernel command line needs to contain fips=1 to switch the kernel to FIPS mode (which also enables a slower FIPS-compliant DRBG)
  • If /boot is on a separate partition, a boot=UUID=<uuid-of-boot-partition> flag needs to be added to the kernel command line for the fips dracut initramfs module to be able to find the expected message authentication code for the kernel binary.

This process is somewhat brittle due to the number of different changes that need to be made. Additionally, fips-mode-setup --disable, which only exists for testing purposes because the compliance requirements do not support switching systems out of FIPS mode, does not undo adding the fips module to the initramfs to avoid a risk that the system will no longer boot afterwards. fips-mode-setup --check subsequently reports an inconsistent configuration, which is frequently confusing users.

This user confusion is one of the reasons why we propose to remove this tool.

Instead, we will remove or have already removed some of these knobs and instead automate them:

  • The system-wide cryptographic policy will automatically follow the fips=1 kernel command line flag to remove the need for the manual switch previously performed by fips-mode-setup. This is already implemented by a dracut module, which will add two bind-mounts before pivoting to the root filesystem if the system is in FIPS mode, but the crypto-policy is not.
  • For systems that are not started using dracut (e.g., containers with systemd), the crypto-policies package ships fips-crypto-policy-overlay.service, which runs early during boot and also applies these bind mounts.
  • Containers started using podman on hosts in FIPS mode did already create these bind mounts, but we are also modernizing that, see containers/common#2130 and containers/common#2174.
  • The crypto-policies package has been adjusted to detect and handle this situation during upgrades and when update-crypto-policies --set is called manually. This also improves the behavior of update-crypto-policies --set in containers in FIPS mode, which was a lot more brittle before.
  • We will enable the dracut fips module on all systems. This is required for unified kernel images anyway. The fips dracut module does nothing if the system is not in FIPS mode (i.e., fips=1 is not on the kernel command line).


The other big reason for removing fips-mode-setup is that it allows switching to FIPS mode after installation, which means that certain algorithmic choices have already been made. For example, cryptsetup will use PBKDF2 as key derivation function in FIPS setup, but Argon2 otherwise. A system with LUKS disk encryption initially set up outside of FIPS mode but switched into FIPS mode later using fips-mode-setup would end up in one of two states: either, non-compliant due to the use of Argon2, or unbootable in case the cryptographic library refuses the attempt to use Argon2. OpenSSH is also affected during installation or first system boot with its hostkey algorithm choices. Additionally, even keys that would be usable in FIPS mode must be considered tainted on systems switched to FIPS mode after installation, because key generation behaves different in FIPS mode (e.g., all RSA keys would have to be thrown away and re-generated).

For these reasons, we have come to the conclusion that the only sane way to create a system in FIPS mode, is to install it in FIPS mode. fips-mode-setup is therefore actively harmful.


Feedback

Users that do not care about compliance but only run Fedora in FIPS mode for testing may not want to reinstall from scratch just for that purpose. For these cases, and when the above limitations are well understood, the fips=1 kernel command line flag can be modified directly, e.g. using 

grubby --update-kernel=ALL --args="fips=1 boot=UUID=$(blkid --output value --match-tag UUID "$(findmnt --first --noheadings -o SOURCE /boot)")"

Users that do not care about compliance that want to switch systems out of FIPS mode can equally use grubby to remove the fips=1 kernel command line flag.

Benefit to Fedora

  • Upstream testing on systems in FIPS mode will use consistent algorithm choices everywhere.
  • Misconfigurations such as the use of the Argon2 key derivation function for LUKS disk encryption in FIPS mode will be reduced.
  • Misconfigurations such as the use of a non-FIPS system-wide cryptographic policy in FIPS mode will automatically be avoided
  • Maintenance for fips-mode-setup can be stopped, freeing up resources for other changes

Scope

  • Proposal owners: Most of the changes mentioned above are incremental improvements that made sense on their own and have already landed. Removal of the fips-mode-setup tool is the remaining step that could not be done without a change proposal and TBD.
  • Other developers: No further changes are expected from other developers. From a user point of view, FIPS mode will continue to work as it did before. The only change is on how to enable FIPS mode. The anaconda installer that used to invoke fips-mode-setup has already been changed to call /usr/libexec/fips-setup-helper provided by the crypto-policies package instead.
  • Release engineering: #Releng issue number
  • Policies and guidelines: not needed for this Change
  • Trademark approval: not needed for this Change
  • Alignment with the Fedora Strategy: This simplifies the ecosystem connections because it reduces the number of downstream changes.

Upgrade/compatibility impact

Systems in FIPS mode that were configured to not use the FIPS system-wide cryptographic policy will see their policy automatically be changed to FIPS mode. Running in FIPS mode with a non-FIPS crypto-policy is considered a misconfiguration.

Scripts that used fips-mode-setup will stop working after the upgrade.

Early Testing (Optional)

Do you require 'QA Blueprint' support? No

How To Test

Testers that will try the three methods outlined above to switch to FIPS mode are welcome. From downstream testing, we expect no issues.

Using dnf reinstall crypto-policies on a system that has the two bind-mounts for the FIPS crypto-policy (i.e., that's in FIPS mode but its crypto-policy was not manually switched to FIPS) should pass without issue, and the files in /etc/crypto-policies/back-ends should correspond to those in /usr/share/crypto-policies/back-ends/FIPS. We also expect no issues here from downstream testing.

Testers that run Fedora containers with systemd on hosts in FIPS mode (i.e., /proc/sys/crypto/fips_enabled contains 1) both with podman and with other container runtimes are very welcome.

User Experience

Users will notice that fips-mode-setup no longer exists. Users that want to switch systems to FIPS mode need to follow different steps.

At the same time, switching to FIPS mode now comes with fewer pitfalls and fewer possibilities for misconfigurations and inconsistencies.

Dependencies

The following packages have already adapted to this potential change and will continue to work:

  • anaconda
  • dracut
  • podman
  • crypto-policies (in particular update-crypto-policies and the package %pre and %post scriptlets)

Contingency Plan

  • Contingency mechanism: We will keep fips-mode-setup and try again next release
  • Contingency deadline: beta freeze (or even later, if required)
  • Blocks release? No


Documentation

Release Notes

The fips-mode-setup command that could be used to switch systems to FIPS mode after installation has been removed.

Switching to FIPS mode is no longer supported after installation. To switch systems to FIPS mode,

  • add fips=1 to the kernel command line of the installer
  • use osbuild-composer with the following customization to build a FIPS-enabled image:
 [customizations]
 fips = true

Disabling FIPS mode is not supported. To disable FIPS mode, re-install your system without enabling FIPS mode.

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/RemoveFipsModeSetup&oldid=725397"