Wiki - https://fedoraproject.org/wiki/Changes/RemoveFipsModeSetup Discussion Thread - https://discussion.fedoraproject.org/t/f42-change-proposal-remove-fips-mode-setup-system-wide/138983 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@xxxxxxxxxx == 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 [https://en.wikipedia.org/wiki/FIPS_140 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 <pre>[customizations]\n fips=true</pre> customization to build an image in FIPS mode * Use `bootc` as documented at https://gitlab.com/fedora/bootc/examples/-/tree/main/fips This will remove all tooling to switching in and out of FIPS mode after installation. Switching after installation is a bad idea anyway, see below for the rationale. Switching out of FIPS mode without reinstalling 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 [https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program 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 turn the `fips=1` kernel command line flag into the single source of truth for whether FIPS mode is enabled. We have already removed or will remove some of the separate knobs and instead automate them to follow the single source of truth: * 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 [https://github.com/dracut-ng/dracut-ng/tree/main/modules.d/01fips-crypto-policies 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. See https://bugzilla.redhat.com/show_bug.cgi?id=2325499. This change is independent of this change proposal, and we will pursue this regardless of whether the community agrees that this change is a good idea, since it does make sense as a separate incremental improvement. * Containers started using `podman` on hosts in FIPS mode did already create these bind mounts, but we are also modernizing that, see [https://github.com/containers/common/issues/2130 containers/common#2130] and [https://github.com/containers/common/pull/2174 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 <pre>grubby --update-kernel=ALL --args="fips=1 boot=UUID=$(blkid --output value --match-tag UUID "$(findmnt --first --noheadings -o SOURCE /boot)")"</pre> The `boot=UUID=<partition-uuid>` part of this command is only required if `/boot` is a separate partition, because the `fips` dracut initramfs module will otherwise not be able to locate the message authentication code to verify the integrity of the kernel image. 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: [https://pagure.io/releng/issue/12472 #12472] * 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 == * 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 after installation has subtle bugs and is no longer recommended. 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 the `fips=1` kernel command line flag in your `Containerfile` as documented in the example at https://gitlab.com/fedora/bootc/examples/-/tree/main/fips To disable FIPS mode, re-install your system without enabling FIPS mode. Disabling FIPS mode without reinstalling does not make sense from a compliance point of view. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
