Backport fips-crypto-policies module #35
Conversation
neverpanic
force-pushed
the
cllang-autofips-policy
branch
from
e7da2c1
to
f230d5f
Compare
|
Let me sync dist-git first, and then I'll merge&build. |
|
FWIW, I can reproduce the OpenSuSE test failures locally, and they seem to be caused by |
|
Sure, np, I've just not yet removed the tests. I plan to focus solely on Fedora here. |
neverpanic
force-pushed
the
cllang-autofips-policy
branch
from
f230d5f
to
93384bf
Compare
|
I've rebased on commit that should re-establish the sync with dist-git. |
|
Hi, thanks for working on this -- I just realized there's 103 rebase pending for a long time, and I'll put this on top of it (just in case there're some merge conflicts). Will do the rebase fully (and resync) manually, as AFAIK currently it |
|
Sure. Just let me know if I can help by rebasing this PR, or doing anything else. |
For a system that uses crypto-policies to be switched to FIPS mode correctly, it needs to be - booted with `fips=1` on the kernel command line - switched to the FIPS crypto-policy (or a policy derived from it) - have the fips dracut module enabled On older systems, there were additional steps, for example, creating `/etc/system-fips`. We have repeatedly seen inconsistencies between those different toggles, either because the user space tooling to switch between those does not (for reliability, maintainability, and compliance reasons) undo some of the steps it does when disabling FIPS mode, or because other installation methods (bootc, containers, image builder) independently do some of those steps. Eventually, all of these ended with user confusion. We can avoid this situation by eliminating the difference by treating the `fips=1` kernel command line switch as a single source of truth, and making all others follow automatically. This module provides this for crypto-policies, by adding bind-mounts before pivot if the system has not already been switched to a FIPS-based crypto-policy. This requires some support from the crypto-policies package (because it needs to deal with the bind mounts when a user calls `update-crypto-policies --set`), so make it a no-op unless - `fips=1` is on the kernel command line - crypto-policies is installed - crypto-policies supports the bind-mounts (indicated by the presence of the `default-fips-config` file) - the policy isn't already FIPS These checks should make this safe to add to the initramfs on all current systems. The bind-mounts also need to happen in the initramfs already, because systemd links against OpenSSL, and doing them later means that systemd will start with an OpenSSL configuration that isn't tailored for FIPS. See also [1], which adds the user space support to crypto-policies, along with a systemd service that does the same steps in case dracut hasn't already done them (which is useful for environments that don't use an initramfs like containers). [1]: https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/191 Signed-off-by: Clemens Lang <[email protected]> (cherry picked from commit bd3c1e1cc2f656f7ee4ff47e00ca716d52a86a3d)
(cherry picked from commit a2096dafdbfc88eed91ce34b1f4d27e7eb7ca839)
Conflicts:
modules.d/01fips-crypto-policies/module-setup.sh
Due to upstream e6117b92fa0108dbaf9ea3ac0ec8f5a02487c812, which
was not cherry-picked. Resolved the conflict by keeping the
functions (i.e., undoing the cleanup of the upstream commit).
Signed-off-by: Clemens Lang <[email protected]>
neverpanic
force-pushed
the
cllang-autofips-policy
branch
from
93384bf
to
9d91ff8
Compare
|
I rebased my three commits on top of main. |
|
Thanks! I'll merge this right after fixing the CI (in hour or two). |
|
Sorry, I just realized you're changing the spec with entries and dist. |
Users that enable FIPS mode using
fips-mode-seutp --enableand later disable it usingfips-mode-setup --disablecommonly notice thatfips-mode-setup --checktells them that their system is in an inconsistent state. This is because (among other things)fips-mode-setup --disabledoes not undo adding thefipsmodule to the initramfs out of an abundance of caution to avoid breaking a system's boot.This situation is not great, because users are often confused by the
fips-mode-setup --checkmessage and will not stop usingfips-mode-setup --disable(despite the manpage clearly saying that it's for testing purposes only and unsupported).We plan on solving this issue once and for all in CentOS 10 Stream by eliminating the possibility of inconsistency. For this to work, we need a single source of truth that decides whether FIPS is enabled or not, and all other parts need to follow along automatically. The obvious choice for the single source of truth is the kernel command line, i.e. if it contains fips=1, FIPS should be enabled, if it doesn't or it contains fips=0, FIPS mode should be disabled.
This backport from upstream achieves a significant part of that, by automatically switching the crypto-policy to FIPS on systems booted with
fips=1on the kernel command line. The crypto-policies package has been adjusted to detect and transparently deal with situation (especially during package updates) in F41 and rawhide with upstream commit e7b94d2a309c5348aa534c5a1d9718261a2ec89a.Cherry picked from commits bd3c1e1cc2f656f7ee4ff47e00ca716d52a86a3d and a2096dafdbfc88eed91ce34b1f4d27e7eb7ca839.
Related: CRYPTO-13556