Remove fips-mode-setup
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-21
- [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, aboot=UUID=<uuid-of-boot-partition>
flag needs to be added to the kernel command line for thefips
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 byfips-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 shipsfips-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 whenupdate-crypto-policies --set
is called manually. This also improves the behavior ofupdate-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. Thefips
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 thecrypto-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 particularupdate-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
- https://github.com/dracut-ng/dracut-ng/pull/576
- https://github.com/containers/common/issues/2130
- https://github.com/containers/common/pull/2174
- https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/205
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
- use
bootc
and add thefips=1
kernel command line flag in yourContainerfile
as documented in the example at https://gitlab.com/fedora/bootc/examples/-/tree/main/fips
Disabling FIPS mode is not supported. To disable FIPS mode, re-install your system without enabling FIPS mode.