RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1156406 - NSS fails to access sql:/etc/pki/nssdb in system FIPS mode
Summary: NSS fails to access sql:/etc/pki/nssdb in system FIPS mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Elio Maldonado Batiz
QA Contact: Hubert Kario
URL:
Whiteboard:
: 1035509 (view as bug list)
Depends On:
Blocks: 717789 839624
TreeView+ depends on / blocked
 
Reported: 2014-10-24 11:58 UTC by Hubert Kario
Modified: 2015-05-07 14:48 UTC (History)
8 users (show)

Fixed In Version: nss-softokn-3.16.2.3-5.el7
Doc Type: Bug Fix
Doc Text:
Cause: softoken performed unwarranted strict checks in FIPS mode in a reload situation Consequence: Users coudn't import a key to a user's default database pk12util nor list the global database Fix: The nss softoken module as been changed to skip the fips checks if the action is adding or deleting a slot. Result: Users can now perform the database listing and import operations on fips mode.
Clone Of:
Environment:
Last Closed: 2015-03-05 08:29:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Patch v1 (1.34 KB, patch)
2014-12-19 12:55 UTC, Kai Engert (:kaie) (inactive account) 		rrelyea: review+
Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1113632 0 None None None 2019-06-27 02:10:41 UTC
Red Hat Product Errata RHBA-2015:0364 0 normal SHIPPED_LIVE nss, nss-softokn, nss-util, and nspr bug fix and enhancement update 2015-03-05 12:51:43 UTC

Description Hubert Kario 2014-10-24 11:58:12 UTC 
Description of problem:
When importing a key to a user's default database pk12util returns following error:
"pk12util: function failed: SEC_ERROR_UNKNOWN_PKCS11_ERROR: Unknown PKCS #11 error."
After that all accesses to the database using certutil or modutil cause the same issue.

Version-Release number of selected component (if applicable):
nss-3.16.2-7.el7_0.x86_64
nss-util-3.16.2-2.el7_0.x86_64
nss-softokn-3.16.2-2.el7_0.x86_64
nspr-4.10.6-1.el7_0.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Enable fips mode in system
2. Create a pkcs#12 file with key and certificate
3. Try to import it to default database (sql:/etc/pki/nssdb) as a regular user

Actual results:
[nsstestuser@sheep-63 ~]$ ls -lha ~/.pki/nssdb
ls: cannot access /home/nsstestuser/.pki/nssdb: No such file or directory
[nsstestuser@sheep-63 ~]$ modutil -list -dbdir sql:/etc/pki/nssdb/

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal Crypto Services
         slots: 1 slot attached
        status: loaded

         slot: NSS FIPS 140-2 User Private Key Services
        token: NSS FIPS 140-2 Certificate DB

  2.
         slots: There are no slots attached to this module
        status: Not loaded
-----------------------------------------------------------
[nsstestuser@sheep-63 ~]$ modutil -list "NSS Internal Crypto Services" -dbdir sql:/etc/pki/nssdb/

-----------------------------------------------------------
Name: NSS Internal Crypto Services
Library file: **Internal ONLY module**
Manufacturer: Mozilla Foundation
Description: NSS Internal Crypto Services
PKCS #11 Version 2.20
Library Version: 3.16
Cipher Enable Flags: None
Default Mechanism Flags: None

  Slot: NSS FIPS 140-2 User Private Key Services
  Slot Mechanism Flags: None
  Manufacturer: Mozilla Foundation
  Type: Software
  Version Number: 3.16
  Firmware Version: 2.0
  Status: Enabled
  Token Name: NSS FIPS 140-2 Certificate DB
  Token Manufacturer: Mozilla Foundation
  Token Model: NSS 3
  Token Serial Number: 0000000000000000
  Token Version: 0.0
  Token Firmware Version: 0.0
  Access: NOT Write Protected
  Login Type: Public (no login required)
  User Pin: Initialized

-----------------------------------------------------------
[nsstestuser@sheep-63 ~]$ pk12util -i nsstestusercert.p12 -n nsstestusercert_2 -d sql:/etc/pki/nssdb
pk12util: function failed: SEC_ERROR_UNKNOWN_PKCS11_ERROR: Unknown PKCS #11 error.
[nsstestuser@sheep-63 ~]$ modutil -list "NSS Internal Crypto Services" -dbdir sql:/etc/pki/nssdb/
modutil: function failed: SEC_ERROR_UNKNOWN_PKCS11_ERROR: Unknown PKCS #11 error.

Expected results:
Import works, doesn't break user database.

Additional info:
Removing the ~/.pki/nssdb directory does restore the modutil functionality.
It works without an issue in non-FIPS mode.
Comment 1 Bob Relyea 2014-11-20 16:29:56 UTC 
>  Login Type: Public (no login required)
>  User Pin: Initialized

This one still looks like it's an issue, Elio could you and Kai run this to ground. If he problem is in softokn, we need to get to it right away.

bob
Comment 15 Kai Engert (:kaie) (inactive account) 2014-12-18 16:00:51 UTC 
Bob, any idea what's going wrong here?
Comment 17 Bob Relyea 2014-12-18 18:34:51 UTC 
> During the fifth time, we go through secmod_LoadPKCS11Module and arrive in 
> secmod_ModuleInit.
> We arrive at the very last error check in the function:
>
>    	if (crv != CKR_OK)  {
>	    PORT_SetError(PK11_MapError(crv));
>	    return SECFailure;
>	}
>
> (gdb) print crv
> $34 = 401
> (gdb) print /x 401
> $35 = 0x191
>
> util/pkcs11t.h
> 1125:#define CKR_CRYPTOKI_ALREADY_INITIALIZED      0x00000191

This is what I would expect from C_Initialize(). softoken is already loaded (to load (sql:/home/kaie/.pki/nssdb), we are trying to load a new database (sql:/etc/pki/nssdb). We were expecting this earlier, though. See the line:

    crv = PK11_GETTAB(mod)->C_Initialize(pInitArgs);
    if (CKR_CRYPTOKI_ALREADY_INITIALIZED == crv) {

This menas we are calling C_Initialize() and getting a failure other than CKR_CRYPOKI_ALREADY_INITIALIZED, We then retry C_Initailize with different parameters and get the CKR_CRYPTOKI_ALREADY_INITIALIZED. What we need to know is what error code are we getting on the initial call and why (and why don't we get that code on set second call.

What we do know is the error isn't CKR_NETSCAPE_CERTDB_FAILED or CKR_NETSCAPE_KEYDB_FAILED because we don't retry the C_Initialize() call at that point.

bob
Comment 18 Kai Engert (:kaie) (inactive account) 2014-12-18 18:45:28 UTC 
I set a breakpoint in FC_Initialize.

The first time it gets called during the third call to SECMOD_LoadModule (see comment 14).

It succeeds, no errors!

Later Initialize gets called again, and because nsf_init is already set, it returns with CKR_CRYPTOKI_ALREADY_INITIALIZED.


The first call to FC_Initialize has this stack:

#0  FC_Initialize (pReserved=0x7fffffffdd60) at fipstokn.c:442
#1  0x00007ffff768f7ef in secmod_ModuleInit (mod=mod@entry=0x635fb0, reload=reload@entry=0x7fffffffdeb0, alreadyLoaded=alreadyLoaded@entry=0x7fffffffdde4) at pk11load.c:232
#2  0x00007ffff768fe1a in secmod_LoadPKCS11Module (mod=mod@entry=0x635fb0, oldModule=oldModule@entry=0x7fffffffdeb0) at pk11load.c:480
#3  0x00007ffff769bafb in SECMOD_LoadModule (
    modulespec=modulespec@entry=0x635930 "library= module=\"NSS User database\" parameters=\"configdir='sql:/home/kaie/.pki/nssdb'  certPrefix='' keyPrefix='' secmod='secmod.db' flags=readOnly updatedir='' updateCertPrefix='' updateKeyPrefix='' "..., 
    parent=parent@entry=0x6327e0, recurse=recurse@entry=1) at pk11pars.c:1014
#4  0x00007ffff769bbf0 in SECMOD_LoadModule (
    modulespec=modulespec@entry=0x6352a0 "library=\"libnsssysinit.so\" name=\"NSS Internal PKCS #11 Module\" NSS=\"Flags=internal,moduleDBOnly,critical trustOrder=75 cipherOrder=100 slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,"..., 
    parent=parent@entry=0x632ff0, recurse=recurse@entry=1) at pk11pars.c:1049
#5  0x00007ffff769bbf0 in SECMOD_LoadModule (
    modulespec=modulespec@entry=0x633b60 "name=\"NSS Internal Module\" parameters=\"configdir='sql:/etc/pki/nssdb' certPrefix='' keyPrefix='' secmod='secmod.db' flags=readOnly updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updat"..., 
    parent=parent@entry=0x0, recurse=recurse@entry=1) at pk11pars.c:1049
#6  0x00007ffff766b10b in nss_InitModules (isContextInit=0, optimizeSpace=<optimized out>, forceOpen=<optimized out>, noModDB=<optimized out>, noCertDB=<optimized out>, readOnly=<optimized out>, pwRequired=<optimized out>, configStrings=<optimized out>, 
    configName=<optimized out>, updateName=<optimized out>, updateID=<optimized out>, updKeyPrefix=<optimized out>, updCertPrefix=<optimized out>, updateDir=0x7ffff773bf2d "", secmodName=<optimized out>, keyPrefix=0x419de4 "", certPrefix=0x419de4 "", 
    configdir=<optimized out>) at nssinit.c:435
#7  nss_Init (configdir=<optimized out>, certPrefix=certPrefix@entry=0x419de4 "", keyPrefix=keyPrefix@entry=0x419de4 "", secmodName=secmodName@entry=0x41b65f "secmod.db", updateDir=updateDir@entry=0x7ffff773bf2d "", updCertPrefix=updCertPrefix@entry=0x7ffff773bf2d "", 
    updKeyPrefix=updKeyPrefix@entry=0x7ffff773bf2d "", updateID=updateID@entry=0x7ffff773bf2d "", updateName=updateName@entry=0x7ffff773bf2d "", initContextPtr=initContextPtr@entry=0x0, initParams=initParams@entry=0x0, readOnly=readOnly@entry=1, 
    noCertDB=noCertDB@entry=0, noModDB=noModDB@entry=0, forceOpen=forceOpen@entry=0, noRootInit=noRootInit@entry=0, optimizeSpace=optimizeSpace@entry=0, noSingleThreadedModules=noSingleThreadedModules@entry=0, 
    allowAlreadyInitializedModules=allowAlreadyInitializedModules@entry=0, dontFinalizeModules=dontFinalizeModules@entry=0) at nssinit.c:639
#8  0x00007ffff766ba23 in NSS_Initialize (configdir=<optimized out>, certPrefix=certPrefix@entry=0x419de4 "", keyPrefix=keyPrefix@entry=0x419de4 "", secmodName=secmodName@entry=0x41b65f "secmod.db", flags=flags@entry=1) at nssinit.c:813
#9  0x000000000040dea3 in certutil_main (argc=<optimized out>, argv=<optimized out>, initialize=initialize@entry=1) at certutil.c:2857
#10 0x000000000040625b in main (argc=<optimized out>, argv=<optimized out>) at certutil.c:3544


The second time we have this stack:

#1  0x00007ffff768f7ef in secmod_ModuleInit (mod=mod@entry=0x67c660, reload=reload@entry=0x7fffffffdeb0, alreadyLoaded=alreadyLoaded@entry=0x7fffffffdde4) at pk11load.c:232
#2  0x00007ffff768fe1a in secmod_LoadPKCS11Module (mod=mod@entry=0x67c660, oldModule=oldModule@entry=0x7fffffffdeb0) at pk11load.c:480
#3  0x00007ffff769bafb in SECMOD_LoadModule (
    modulespec=modulespec@entry=0x635c50 "library= module=\"NSS system database\" parameters=\"configdir='sql:/etc/pki/nssdb' tokenDescription='NSS system database' flags=readonly\" NSS=\"trustOrder=80 cipherOrder=100 slotParams={0x00000001=[slotF"..., 
    parent=parent@entry=0x6327e0, recurse=recurse@entry=1) at pk11pars.c:1014
#4  0x00007ffff769bbf0 in SECMOD_LoadModule (
    modulespec=modulespec@entry=0x6352a0 "library=\"libnsssysinit.so\" name=\"NSS Internal PKCS #11 Module\" NSS=\"Flags=internal,moduleDBOnly,critical trustOrder=75 cipherOrder=100 slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,"..., 
    parent=parent@entry=0x632ff0, recurse=recurse@entry=1) at pk11pars.c:1049
#5  0x00007ffff769bbf0 in SECMOD_LoadModule (
    modulespec=modulespec@entry=0x633b60 "name=\"NSS Internal Module\" parameters=\"configdir='sql:/etc/pki/nssdb' certPrefix='' keyPrefix='' secmod='secmod.db' flags=readOnly updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updat"..., 
    parent=parent@entry=0x0, recurse=recurse@entry=1) at pk11pars.c:1049
#6  0x00007ffff766b10b in nss_InitModules (isContextInit=0, optimizeSpace=<optimized out>, forceOpen=<optimized out>, noModDB=<optimized out>, noCertDB=<optimized out>, readOnly=<optimized out>, pwRequired=<optimized out>, configStrings=<optimized out>, 
    configName=<optimized out>, updateName=<optimized out>, updateID=<optimized out>, updKeyPrefix=<optimized out>, updCertPrefix=<optimized out>, updateDir=0x7ffff773bf2d "", secmodName=<optimized out>, keyPrefix=0x419de4 "", certPrefix=0x419de4 "", 
    configdir=<optimized out>) at nssinit.c:435
#7  nss_Init (configdir=<optimized out>, certPrefix=certPrefix@entry=0x419de4 "", keyPrefix=keyPrefix@entry=0x419de4 "", secmodName=secmodName@entry=0x41b65f "secmod.db", updateDir=updateDir@entry=0x7ffff773bf2d "", updCertPrefix=updCertPrefix@entry=0x7ffff773bf2d "", 
    updKeyPrefix=updKeyPrefix@entry=0x7ffff773bf2d "", updateID=updateID@entry=0x7ffff773bf2d "", updateName=updateName@entry=0x7ffff773bf2d "", initContextPtr=initContextPtr@entry=0x0, initParams=initParams@entry=0x0, readOnly=readOnly@entry=1, 
    noCertDB=noCertDB@entry=0, noModDB=noModDB@entry=0, forceOpen=forceOpen@entry=0, noRootInit=noRootInit@entry=0, optimizeSpace=optimizeSpace@entry=0, noSingleThreadedModules=noSingleThreadedModules@entry=0, 
    allowAlreadyInitializedModules=allowAlreadyInitializedModules@entry=0, dontFinalizeModules=dontFinalizeModules@entry=0) at nssinit.c:639
#8  0x00007ffff766ba23 in NSS_Initialize (configdir=<optimized out>, certPrefix=certPrefix@entry=0x419de4 "", keyPrefix=keyPrefix@entry=0x419de4 "", secmodName=secmodName@entry=0x41b65f "secmod.db", flags=flags@entry=1) at nssinit.c:813
#9  0x000000000040dea3 in certutil_main (argc=<optimized out>, argv=<optimized out>, initialize=initialize@entry=1) at certutil.c:2857
#10 0x000000000040625b in main (argc=<optimized out>, argv=<optimized out>) at certutil.c:3544
Comment 19 Kai Engert (:kaie) (inactive account) 2014-12-18 18:50:43 UTC 
The only difference (besides pointer values) between the two stacks is in the parameters to SECMOD_LoadModule.
Comment 20 Bob Relyea 2014-12-18 19:24:07 UTC 
> Later Initialize gets called again, and because nsf_init is already set, it 
> returns with CKR_CRYPTOKI_ALREADY_INITIALIZED.

This is exactly how it's supposed to be. NSS depends on CKR_CRYPTOKI_ALREADY_INITIALIZED being set to know it needs to later call SECMOD_OpenNewSlot(). 

The question is why is 

    crv = PK11_GETTAB(mod)->C_Initialize(pInitArgs);
    if (CKR_CRYPTOKI_ALREADY_INITIALIZED == crv) {

Not getting triggered? (See my comment 17).

bob
Comment 21 Bob Relyea 2014-12-18 19:30:08 UTC 
Oh, I bet the problem isn't that C_Initialize is returning a different error, it's that rv = secmod_handleReload(oldModule, mod); is failing, which probably  means it's failing in SECMOD_OpenNewSlot().

SECMOD_OpenNewSlot() works by creating a new special objected call CKO_NETSCAPE_NEWSLOT, so I'm guessing the real error code you need to look at is the error from FC_CreateObject(). (probably the first call after the second FC_Initialialize call...).
Comment 22 Kai Engert (:kaie) (inactive account) 2014-12-18 19:45:38 UTC 
You're guessing correctly.

I just found out independently that secmod_handleReload() is what's failing (I had compared the flow with a non-fips fedora computer).

Yes, secmod_handleReload() returns false.

Thanks for the hint to look for FC_CreateObject(), which probbaly saved me a lot of time.

That functions starts with SFTK_FIPSCHECK(), which fails.

sftk_fipsCheck returns 257, 0x101, which seems to be
#define CKR_USER_NOT_LOGGED_IN                0x00000101
Comment 23 Kai Engert (:kaie) (inactive account) 2014-12-18 20:21:13 UTC 
Bob, why does NSS complain about "not logged in", if the database is being opened read-only and there isn't any password set?
Comment 24 Bob Relyea 2014-12-18 23:29:44 UTC 
Yeah, it's the fips token. The actual database it's using is sql:/home/kaie/.pki/nssdb

We should look at the object class and only do SFTK_FIPSFATALCHECK(); if the class is CKO_NETSCAPE_NEWSLOT or CKO_NETSCAPE_DELSLOT

bob
Comment 25 Kai Engert (:kaie) (inactive account) 2014-12-19 12:07:03 UTC 
Bob, your comments are very brief, so I have to do a lot of guessing. I had hoped that you would provide a patch, since I don't know this code.

I'm trying to help, by trying to deduce what change you're proposing.

There dosn't seem to be a call to SFTK_FIPSFATALCHECK() involved, all I see is a call to SFTK_FIPSCHECK().

Did you intend to suggest
  "call SFTK_FIPSCHECK() **ONLY** if class is NEWSLOT/DELSLOT"
?
Comment 26 Kai Engert (:kaie) (inactive account) 2014-12-19 12:44:34 UTC 
I think I misunderstood your suggestion.

Initially I understood "only do any checking if condition is met"

Now I think your suggestion is:

  if NEWSLOT/DELSLOT, then don't do FIPSCHECK, but only do FATALCHECK.
Comment 27 Kai Engert (:kaie) (inactive account) 2014-12-19 12:55:29 UTC 
Created attachment 971114 [details]
Patch v1

This patch works for me, both certutil list and pk12util import.

Bob, is this what you wanted?

I had to expand the macros, because of the variable definitions.

Can you please
- review
- grant devel_ack

Thanks
Comment 28 Kai Engert (:kaie) (inactive account) 2014-12-19 12:56:43 UTC 
In case anyone wants to do early testing, scratch build is here:
https://brewweb.devel.redhat.com/taskinfo?taskID=8416546

Patch204:   limit-create-fipscheck.patch
%patch204 -p0 -b .limit-create-fipscheck
Comment 29 Kai Engert (:kaie) (inactive account) 2014-12-19 13:22:31 UTC 
I filed an upstream bug, to get the fix into upstream NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=1113632
Comment 30 Kai Engert (:kaie) (inactive account) 2014-12-19 14:02:18 UTC 
patch passes upstream test suite.
Comment 32 Bob Relyea 2015-01-08 22:06:29 UTC 
blocker justification: This patch blocks FIPS validation of RHEL-7.
Comment 37 errata-xmlrpc 2015-03-05 08:29:00 UTC 
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, 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://rhn.redhat.com/errata/RHBA-2015-0364.html
Comment 38 Hubert Kario 2015-05-07 14:48:05 UTC 
*** Bug 1035509 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.