Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1109793 - Can't initialize a null password database if persistently in FIPS mode.
Can't initialize a null password database if persistently in FIPS mode.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss-softokn (Show other bugs)
7.1
All Linux
high Severity high
: rc
: ---
Assigned To: Elio Maldonado Batiz
Ondrej Moriš
: Reopened
Depends On:
Blocks: 717789
  Show dependency treegraph
 
Reported: 2014-06-16 07:23 EDT by Ondrej Moriš
Modified: 2015-03-05 03:28 EST (History)
5 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-05 03:28:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to allow init to level1 (2.81 KB, patch)
2014-11-04 17:36 EST, Bob Relyea
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0364 normal SHIPPED_LIVE nss, nss-softokn, nss-util, and nspr bug fix and enhancement update 2015-03-05 07:51:43 EST

  None (edit)
Description Ondrej Moriš 2014-06-16 07:23:37 EDT
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 14:03:56 EDT
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 Hubert Kario 2014-10-24 10:17:12 EDT
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 Hubert Kario 2014-10-24 10:35:35 EDT
nss-sysinit-3.16.2-7.el7_0.x86_64 is also installed
Comment 4 Bob Relyea 2014-11-04 17:36:12 EST
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 17:36:55 EST
Created attachment 953866 [details]
patch to allow init to level1
Comment 14 errata-xmlrpc 2015-03-05 03:28:01 EST
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.