On 10/21/2016 07:04 AM, Rob Crittenden wrote:
I'm trying to figure out how to dynamically enable FIPS support for
NSS Contexts.
I started with multinit.c and initialize FIPS right after calling
NSS_InitContext() using this:
So you can't change the state of an already open database. NSS will
switch all new databases that are opened, and idle the old ones
(basically they are open, but not really accessible).
if (!PK11_IsFIPS()) {
fprintf(stderr, "Initializing FIPS\n");
SECMODModule *mod = SECMOD_GetInternalModule();
if (!mod) {
fprintf(stderr, "No module!?\n");
exit(1);
}
char * internal_name = PR_smprintf("%s",
SECMOD_GetInternalModule()->commonName);
if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) ||
!PK11_IsFIPS()) {
fprintf(stderr, "Unable to enable FIPS mode on
certificate database\n");
exit(1);
}
I'm executing it like this, initializing only db1 and db2 as contexts:
So when you do an initcontext, you're main database is usually not the
same as the main database when you open NSS, so it won't get
automatically switched.
Is there a reason you are trying to do a dynamic switch to FIPS mode
from within a library? (I'd like to know the use case).
Dynamic switching is a pretty careful choreographed dance that
applications like mozilla can execute with care. It usually involves
both fips and non-fips tokens opened for a short period until all the
references can be cleared. Databases opened before the switch will
almost certainly be inaccessible.
$ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command
list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly
--order 12zi
This is the output:
$ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command
list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly
--order 12zi
* initializing with order "12zi"*
*NSS_Init for lib1*
Checking for FIPS
Initializing FIPS
*Executing nss command "list_certs" for lib1*
cacert CTu,Cu,Cu
* Slot=NSS FIPS 140-2 Certificate DB*
* Nickname=cacert*
*
