Store and enforce that FIPS state doesn't change in an installation #7582
Conversation
It is possible for a user to change their FIPS state after installation. It is important to store the original configured state. Switching between states after installation is not supported. On upgrade try to piece together what the original state was. We can use certmonger to help here. It stores the NSS token name where the keys were generated. 'NSS Certificate DB' is the non-FIPS NSS token name. If this matches the certmonger token then IPA was originally installed with FIPS disabled. Otherwise we can rely on tasks.is_fips_enabled() to obtain the state. Fixes: https://pagure.io/freeipa/issue/7423 Signed-off-by: Rob Crittenden <[email protected]>
If the value of the initial installation state of FIPS is stored then enforce that it hasn't changed on startup. This will be disruptive for those users who have gone from FIPS -> non-FIPS or vice versa because IPA will refuse to stop and there is no switch to allow it. Switching states will prevent certificate renewal because certmonger will attempt to use the wrong token. Signed-off-by: Rob Crittenden <[email protected]>
|
In general, this is a good approach. I have one question, though: how this will work with externally-issued certificates which aren't tracked via certmonger? If we do |
|
There isn't anything we can do about externally provided certs because we can't know how the private keys were generated. I suppose that's a weakness in my patch. If you install with non-FIPS without and IPA CA then enable FIPS and replace the certs then the stored fips value would be incorrect. So I'll have to think about how to handle that. Note that on upgrade this will affect anyone who has done a switch so we could see a mass of users with startup failures. We'll need a plan to deal with that too, if we want enforcement. |
|
Let's say we get to external CA case. Even in this case we can look at the dirsrv NSS database as it still be there, thus it will be possible to detect a token name in it. Lack of private keys in the dirsrv NSS database would mean there was a FIPS mode change between when keys were put in the database and when we are looking at them. |
|
It depends on your scenario. Is this user-provided certs on installation or afterward using ipa-server-certinstall? For a new installation this patch will store the state of FIPS on install completion, ignoring the token name. So if the system was in FIPS mode then the NSS token used will reflect that regardless of how the keys were generated and the fips state will be True. For replacing existing certificates, even IPA ones, using ipa-server-certinstall then we have no way to validate that the provided keys and certificates are FIPS-compliant. This won't change the stored fips state or token names. The certmonger token name will match how the system was configured when ipa-server-install was executed (or when ipa-server-upgrade made a determination of the value). |
|
I am thinking about the scenario where IPA got installed with external certificates and later the code was updated to get this check. So
If the installation happened in non-FIPS mode, then switch to FIPS mode happened and then code was upgraded to handle FIPS, what can we do here? I think this is the case where we need to focus on. |
|
The state is recorded either at installation time or when ipa-server-upgrade is executed and enforced with ipactl. For the case of user-provided certificates, with this patch the FIPS value will be recorded at installation. If the user flips the FIPS state then yes, this could cause IPA to not start. We should have enough information at the point we record the fips state to know which user-provided certs were passed in. We could skip storing the state in that case to avoid issues. On upgrade if there is no fips state recorded it will attempt to deduce it. This will fail because the patch uses the certmonger token to determine status and we don't track user-provided certs. So it will remain missing from sysrestore.state. If the state is missing then ipactl will skip the fips check. I am thinking about the scenario where IPA got installed with external certificates and later the code was updated to get this check. So ipactl start will attempt to cross-check FIPS status. This is what I'd like to handle properly. Your scenarios assume that ipactl is recording the state when it doesn't. It merely compares the stored state to the current value of tasks.is_fips_enabled(). But you correctly point out that if the system FIPS state is changed then it will cause ipactl to fail to start. This is quite harsh but it's the only opportunity to get the user's attention. I did say this would be controversial. We can drop the enforcement patch and rely on healthcheck to report the issue. |
The first patch adds a new state variable, fips, to retain the state of FIPS enablement on the server when IPA, or a replica, is installed. If on upgrade this state is not present then it will attempt to deduce what the initial state was based on the token name stored in certmonger. If the value is not clear then it is skipped.
The second patch will enforce that the FIPS state has not changed from the initial value when ipactl start or restart is called. If the state value is not present then it allows the command to proceed. There is no skip option.
This is easily fooled in any number of ways including:
If someone did these then, to me, it demonstrates that they don't really care about or understand what the system state is and actually being FIPS-compliant. I don't think there is a lot we can do about that. But this will enforce on the system if they try to change the FIPS state post installation, which is unsupported.
https://pagure.io/freeipa/issue/7423