1109793 – Can't initialize a null password database if persistently in FIPS mode.

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 1109793 - Can't initialize a null password database if persistently in FIPS mode.

Summary: Can't initialize a null password database if persistently in FIPS mode.

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	nss-softokn
Sub Component:
Version:	7.1
Hardware:	All
OS:	Linux
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Elio Maldonado Batiz
QA Contact:	Ondrej Moriš
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	717789
TreeView+	depends on / blocked

Reported:	2014-06-16 11:23 UTC by Ondrej Moriš
Modified:	2015-03-05 08:28 UTC (History)
CC List:	5 users (show)
Fixed In Version:	nss-softokn-3.16.2-12.el7
Doc Type:	Bug Fix
Doc Text:	Cause: nss softoken prevented initializing a database with a NULL password if the system was in FIPS mode. Consequence: With NSS DB without no password users weren't be allowed acccces without being prompted for a password. Fix: The nss softokn mode has been changed to switch initialization to FIPS level 1 which doesn't require a password. Result: Users of an NSS DB without password and are now allowed access without being prompted for a password.
Clone Of:
Environment:
Last Closed:	2015-03-05 08:28:01 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
patch to allow init to level1 (2.81 KB, patch) 2014-11-04 22:36 UTC, Bob Relyea	no flags	Details \| Diff
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Bugzilla	1088398	1	None	None	None	2021-01-20 06:05:38 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

Internal Links: 1088398

Description Ondrej Moriš 2014-06-16 11:23:37 UTC

Description of problem:

This bug is for tracking issue discovered in BZ#1020395#c14 [1].

When NSS DB has no password set (ie. "" - NULL string) FIPS level 1 should be allowed without prompting password. This is true when the system is not in FIPS mode (ie. in particular, kernel is booted with fips=0, [*]). However, as described in BZ#1020395#c17 [2], when the system is in FIPS mode, password is required:

# cat /proc/sys/crypto/fips_enabled
1
# rm /tmp/tnssdb/ -rf
# mkdir /tmp/tnssdb
# touch /tmp/foo
# certutil -N -d /tmp/tnssdb -f /tmp/foo 
password file contains no data
# modutil -list -dbdir /tmp/tnssdb/

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

	 slot: NSS FIPS 140-2 User Private Key Services
	token: NSS FIPS 140-2 Certificate DB
-----------------------------------------------------------
#  modutil -list "NSS Internal PKCS #11 Module" -dbdir /tmp/tnssdb/

-----------------------------------------------------------
Name: NSS Internal PKCS #11 Module
Library file: **Internal ONLY module**
Manufacturer: Mozilla Foundation              
Description: NSS Internal Crypto Services    
PKCS #11 Version 2.20
Library Version: 3.15
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.15
  Firmware Version: 0.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: Login required
  User Pin: NOT Initialized

See "Login Type" entry - "Login required", when the system is not in FIPS (but DB is) login is not required, there should be no difference between these cases according to BZ#1020395#c18 [3].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1020395#c14
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1020395#c17
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1020395#c18
[*] https://access.redhat.com/site/solutions/137833

Version-Release number of selected component (if applicable):

nss-3.15.4-2.el7.x86_64
nss-util-3.15.4-2.el7.x86_64
nss-softokn-freebl-3.15.4-2.el7.x86_64
nss-sysinit-3.15.4-2.el7.x86_64
nss-tools-3.15.4-2.el7.x86_64
nss-softokn-3.15.4-2.el7.x86_64

How reproducible:

100%

Steps to Reproduce:

0. Enable fips mode [*].
1. See above.

Actual results:

Login required.

Expected results:

Login not required.

Additional info:

System in FIPS <=> kernel booted with fips=1 (ie. follow steps from [*])
NSS DB in FIPS <=> modutil -fips true <DB> (no matter if system is in FIPS)

I can setup a testing and debugging environment, just let me know.

Comment 1 Bob Relyea 2014-09-26 18:03:56 UTC

OK, what is happening here is the test does not initialize the database properly.

Note the line:   User Pin: NOT Initialized
When you see this with 'login required', this is PKCS #11 magic for 'please initialize the database'.

If you use --empty-password instead:

certutil -N -d /tmp/tnssdb 

You get:

[bob@localhost lowhash]$ modutil -list "NSS Internal FIPS PKCS #11 Module" -dbdir ./test_dir

-----------------------------------------------------------
Name: NSS Internal FIPS PKCS #11 Module
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: RSA:DH:RC2:RC4:DES:AES:CAMELLIA:SEED:SHA1:SHA256:SHA512:MD5:MD2:SSL:TLS

  Slot: NSS FIPS 140-2 User Private Key Services
  Slot Mechanism Flags: RSA:DH:RC2:RC4:DES:AES:CAMELLIA:SEED:SHA1:SHA256:SHA512:MD5:MD2:SSL:TLS
  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

Instead, which is correct behaviour.

bob

Comment 2 Alicja Kario 2014-10-24 14:17:12 UTC

I can't confirm that adding --empty-password fixes the issue:

# grep fips /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-123.8.1.el7.x86_64 root=/dev/mapper/rhel_sheep--63-root ro rd.lvm.lv=rhel_sheep-63/root console=ttyS0 crashkernel=auto vconsole.font=latarcyrheb-sun16 rd.lvm.lv=rhel_sheep-63/swap elevator=noop vconsole.keymap=us LANG=en_US.UTF-8 fips=1 boot=UUID=6bcb1ec6-0d54-4672-aa22-567f55963294

# ls -hla ~/.pki.new/
total 4.0K
drwxr-xr-x. 2 root root    6 Oct 24 16:04 .
dr-xr-x---. 9 root root 4.0K Oct 24 16:04 ..

# certutil -N --empty-password -d sql:/root/.pki.new
*no output, exit code 0*

# modutil -list -dbdir sql:/root/.pki.new

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

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

# modutil -list "NSS Internal PKCS #11 Module" -dbdir sql:/root/.pki.new

-----------------------------------------------------------
Name: NSS Internal PKCS #11 Module
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: Login required
  User Pin: NOT Initialized

-----------------------------------------------------------

# modutil -list "NSS Internal FIPS PKCS #11 Module" -dbdir sql:/root/.pki.new
ERROR: Module "NSS Internal FIPS PKCS #11 Module" not found in database.

Importing a CA certificate to database fails too:
# certutil -A -a -n "RedHatCA" -i /tmp/tmp.XKHf7adTbc/RedHatCA.crt -t "C,C,C" -d sql:/root/.pki.new
certutil: could not authenticate to token NSS FIPS 140-2 Certificate DB.: SEC_ERROR_IO: An I/O error occurred during security authorization.

# rpm -q nss nspr nss-util nss-softokn dracut-fips
nss-3.16.2-7.el7_0.x86_64
nspr-4.10.6-1.el7_0.x86_64
nss-util-3.16.2-2.el7_0.x86_64
nss-softokn-3.16.2-2.el7_0.x86_64
dracut-fips-033-161.el7.x86_64

Comment 3 Alicja Kario 2014-10-24 14:35:35 UTC

nss-sysinit-3.16.2-7.el7_0.x86_64 is also installed

Comment 4 Bob Relyea 2014-11-04 22:36:12 UTC

OK, the problem is not that we aren't interpreting the databases correctly when in system fips mode. The problem is we can't initialize a database with a NULL password if the system is in fips mode. (The modutil isn't the problem, the certutil -N is where we are failing, albeit silently).

 FIPS requires some minimum characteristics for a password on a database, and if our password doesn't meet that standard, we wont accept it. A NULL password doesn't meet that minimum requirement.

I've attached a fix with will allow us to initialize a database with a NULL password. The way the patch works is we allow you to initialize a database either with a FIPS acceptible password, or a NULL  one. If you initilize with the former, we move to level2 and the latter we move to level1. Once you've initialize a password, you can only change it (using a different call). That call will accept only accept a full FIPS password, so you can't move a level2 database to level1 but you can move a level1 database to level2.

Comment 5 Bob Relyea 2014-11-04 22:36:55 UTC

Created attachment 953866 [details]
patch to allow init to level1

Comment 14 errata-xmlrpc 2015-03-05 08:28:01 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

Note You need to log in before you can comment on or make changes to this bug.