search

redhat-plumbers / dracut-fedora

🧢 dracut source-git for Fedora
GNU General Public License v2.0
1 stars 3 forks source link

Backport fips-crypto-policies module #35

Closed neverpanic closed 1 month ago

neverpanic commented 1 month ago

Users that enable FIPS mode using fips-mode-seutp --enable and later disable it using fips-mode-setup --disable commonly notice that fips-mode-setup --check tells them that their system is in an inconsistent state. This is because (among other things) fips-mode-setup --disable does not undo adding the fips module 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 --check message and will not stop using fips-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=1 on 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

pvalena commented 1 month ago

Let me sync dist-git first, and then I'll merge&build.

neverpanic commented 1 month ago

FWIW, I can reproduce the OpenSuSE test failures locally, and they seem to be caused by /dev/disk not existing (for whatever reason). The same failures are also present on main, so this doesn't seem to be a regression introduced by my PR.

pvalena commented 1 month ago

Sure, np, I've just not yet removed the tests. I plan to focus solely on Fedora here.

neverpanic commented 1 month ago

I've rebased on commit that should re-establish the sync with dist-git.

pvalena commented 1 month ago

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 fedpkg import (I plan to implement support directly in source-git in the future).

neverpanic commented 1 month ago

Sure. Just let me know if I can help by rebasing this PR, or doing anything else.

neverpanic commented 1 month ago

I rebased my three commits on top of main.

pvalena commented 1 month ago

Thanks! I'll merge this right after fixing the CI (in hour or two).

pvalena commented 1 month ago

Sorry, I just realized you're changing the spec with entries and dist. The idea is to have it handled automatically (either by custom automation or ideally by packit itself), and bundle the changes from commits to this repo to one commit to dist-git. So I'll drop the dist-git changes, and merge without it. Otherwise it looks good, thanks!

https://github.com/redhat-plumbers/dracut-fedora/pull/39