Bug 1816265

> I assume we can still query NSS using using PK11_IsFIPS()

Yes this will tell you NSS is in FIPS mode. NSS can go into FIPS without the system going into FIPS. (From the application they look identical, well except if NSS is in FIPS mode with the system flag, the application can't switch to non-FIPS mode back to non-FIPS mode on the fly.

> how do we force NSS into fips mode for testing when the system/kernel is not in FIPS mode.
> Can we still use modutil -dbdir sql:/etc/ipsec.d -fips true -force

yes this will force NSS into FIPS mode without the kernel. This is how NSS upstream tests FIPS mode.

> We're aiming to amend the definition of FIPS mode for RHEL 8.3+ to allow
> for operating in FIPS mode without /etc/system-fips file present.
> Source code inspection shows that, despite not being a FIPS module any more,
> libreswan still contains checks
> for both /etc/system-fips and `fips=1` cmdline parameter presence.

Some meta questions here. Does this mean we are changing the validation methods in RHEL 8.3. I see a couple of things that you need to cover:
1) Most validated modules only handle the binary checks if a particular FIP package is installed. NSS does not require it, but other packages do.
2) NSS (as well as the other crypto libraries) get their entropy from the kernel. That means if you want to be validated, then the kernel entropy pool needs to be validated even if the fips=1 flag is not on.
3) The current security policy that we validated with defines going into FIPS mode as fips=1, so technically in RHEL 8.1 and 8.2, putting NSS in FIPS mode without setting fips=1 is not validated.

bob

Bob,
it is not clear to me why the nss database would influence anything?

If the nssdb is not a valid fips database in a system in fips mode it should simply fail loading ?

In general though applications should be able to tell if the system is in fips mode regardless of whether they are going to open a nss database, or not ?

NSS has two FIPS indicators: /proc/sys/crypto/fips and a flag is secmod.db/pkcs11.txt. If the former is 1 then the latter doesn't matter, but if is zero, then the latter controls FIPS/non-FIPS. The latter is how NSS works in the absence of a Linux FIPS system. It's also how we test NSS in FIPS mode when the system isn't. In fact in this very bug, there are instructions how to set the database in FIPS mode when the system isn't.

We could, change NSS_IsFIPS to return true when the system is in FIPS mode, but then we would still run into issues if the customer set the database in FIPS mode and not the system. I think this would be a bad idea, and in the case of libreswan, it would lead to inconsistancies.

NSS_IsFIPS returns the state of NSS. If NSS is not initialized that state is undefined.

> In general though applications should be able to tell if the system is in fips mode regardless of whether they are going to open a nss database, or not ?

That's not the question NSS_IsFIPS() answers. NSS_IsFIPS() answers the question is *NSS* in FIPS mode, not is the system in FIPS mode. Those answers would be different.

So if /proc/sys/crypto/fips is 1 then NSS is stil lnot in FIPS mode ?

Sounds like you make a distinction that has some meaning in the situation where the system does not have a well defined state wrt fips.
But I do not understand the distinction when NSS is running on a system that is clearly in FIPS mode.

Does NSS for example NOT execute self tests at linker load time when the system is in FIPS mode but a database has not been opened yet?

Also additional random though:

would it be possible to add a NSS_SystemIsFIPS() call to respond to the question of whether the system, as a whole, is in FIPS mode, should a change in semantics of NSS_IsFIPS() be undesirable?

NSS always runs the self tests at linker load time... even in non-FIPS mode. It remembers the state of the tests and refuses to initialize FIPS mode if the tests failed. NSS always tries to initialize FIPS mode if /proc/sys/crypto/fips is 1 (Basically NSS treats /proc/sys/crypto/fips as if the database was marked as in fips mode).  If /proc/sys/crypto/fips is 0, then NSS uses the database to determine that it's in FIPS mode. Also if the case that /proc/sys/crypto/fips is set to '0', and application can switch to FIPS mode on the fly (Firefox used to do that with a button to enable or disable FIPS. If /proc/sys/crypto/fips is set to 1, the button would be labelled 'disable FIPS' and grayed out).

RE NSS_SystemIsFIPS(). NSS does have an internal function secmod_GetSystemFIPSEnabled(). We could export it, but I'm wondering what the value is. It seems if we want to have a common system is in FIPS indication, then we should have a function that all our crypto libraries call to get this indication. There is nothing NSS specific about the call.

bob

(In reply to Bob Relyea from comment #18)
> RE NSS_SystemIsFIPS(). NSS does have an internal function
> secmod_GetSystemFIPSEnabled(). We could export it, but I'm wondering what
> the value is. It seems if we want to have a common system is in FIPS
> indication, then we should have a function that all our crypto libraries
> call to get this indication. There is nothing NSS specific about the call.

Bob, the point is close to what you are actually saying.
We are trying to get user applications to stop checkign random system properties themselves and instead use their crypto module interfaces (in libreswan case NSS) to get if the system is in FIPS mode or not.

This way centralize in the certified crypto modules the status management.
*maybe* in future we'll have an API to unify this for the modules themselves, but for now, to us, it is sufficient if applications stop checking random system files. We can easily update and modify crypto modules, we can't esily change all other applications.

For us it is quite key that NSS provides this interface for applications that decided to use NSS as the crypto module.
So if we can export secmod_GetSystemFIPSEnabled() that wuld be great!

Actually in my opinion here the problem lies in the way libreswan handles the check for the FIPS mode. It should not really need to query for the "system is in FIPS mode" but what is interesting for the application is the "NSS is in FIPS mode". And that is correctly determined only when a database is opened. So I do not really see a point in adding a NSS_SystemIsFIPS() call and instead libreswan should change the places where it queries for the FIPS status to do it only after it loads the database.

If the early FIPS mode query is used to bail out if a configuration contains non-fips algorithms, I would say, this is wrong. Because bailing out if a configuration file contains non-fips algorithms is potentially fragile. The fips/non-fips algorithms might change in future and unless the configuration file does not specify any combination of algorithms that is fips approved the configuration file could be usable. Of course that requires filtering out unusable combinations of algorithms after the configuration and the NSS database is loaded. That is a complication but maybe not that big one.

There are a few things that need to be considered here:
1. does libreswan really need to know before opening a database ?
2. Is a workaround possible in thi case
3. do all applications using NSS always:

Sorry sent comment by mistype before I was done, retyping.

There are a few things that need to be considered here:
1. does libreswan really need to know before opening a database ?
2. Is a workaround possible in this case?

3. do all applications using NSS always:
  a) open a database
  b) never need to know if the system is in fips mode when a database is not used

I am pretty sure there are cases where applications do not use a NSS database, and may still need to know is fips mode is enabled, to disable certain functions, we see it done in other cases. for example in the python+openssl case we have some checks in python to see if the system is in FIPS mode to replace the hashes to use those provided by openssl. This is just an example and there may be other ways, but shows that there are a number of applciation that may have good reason to wanting to know.

For those cases we want our crypto modules to provide an API that applications can consult, so that we can easily change the underlying mechanism as need. It is also crtitical for us to be able to easily test that fips mode work by making our modules lie that fips is enable w/o having to reboot the system in fips mode or figuring, for each application if they have an override method and how to use it, etc, etc..

So I understand that libreswan can probably be changed to not need new information from NSS, but I maintain that we should provide that API, and if libreswan finds it easier to use it, then it should.
We can also open bugs against libreswan if it is too greedy in using this information, but those would be additional bugs.

Exporting functions can be tricky because we have to coordinate with upstream. (NSS symbols get marked with the NSS version they were exported with, so we need to make sure the are exported with the same upstream number).

So, I've posted a solution for now that I think gets most of the issues covered for libre swan. I can work with upstream to get NSS_SystemIsFIPS() or SECMOD_SystemIsFIPS() exported (we wouldn't call the external function secmod_GetSystemFIPSEnabled() because the naming conventions tell you the function is an internal NSS function). It's very likely not going to make the next release of NSS because it's pretty close to in the can (so we (red hat) can have it early enough to make our internal schedules).

The proposed solution returns the correct value if nss is initialized, and the value of /proc/sys/crypto/fips_enabled if it's not and uses already exported NSS calls.

bob

Yes there are applications that initialize NSS without a DB. The only way to go into FIPS mode in these applications is either: 1) the system is in FIPS mode, or 2) by hand. fipstest appears to do this: https://bugzilla.redhat.com/show_bug.cgi?id=1831033#c9.

The code in https://bugzilla.redhat.com/show_bug.cgi?id=1831033#c10 is the proposed solution I was referencing in comment 23.

bob

Alright, let's see if it can get upstream fast enough, if not we'll see if Paul can implement the workaround for now.

I have pushed code into upstream, which will be in the RHEL-8.3 rebase to libreswan-3.32

We no longer use /proc so everyone should be happy :)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (libreswan bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:4722