Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230545 - Can not enable NSS FIPS mode
Summary: Can not enable NSS FIPS mode
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-01 13:04 UTC by Kai Engert (:kaie) (inactive account)
Modified: 2008-05-06 19:17 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-06 19:17:37 UTC

Attachments (Terms of Use)

Description Kai Engert (:kaie) (inactive account) 2007-03-01 13:04:57 UTC
Description of problem:
Can not enable NSS FIPS mode.

Version-Release number of selected component (if applicable):
nss-3.11.5-0.6.0.fc6 (and earlier)
nss-3.11.5-0.5.0.fc5 (and earlier)
nss-3.11.5-1.fc7 (and earlier)

How reproducible:
Try to enable FIPS in firefox, you'll notice nothing changes when you try, and
an exception will show up in java console.
(firefox example, but applies to any application wanting to make use of nss fips

Worse scenario: After upgrading from a previous OS release, using a firefox
profile that has FIPS mode already enabled: Starting Firefox will bring up a
report that crypto is not available, and any attempt to use https or SSL will fail.

Steps to Reproduce:
- install nss
- install firefox
- start firefox
- go to prefs
- set a crypto master password
- go to advanced encryption security devices
- click the "enable fips" button

Actual results:
- Nothing happens
- exception shown on javascript / error console

Expected results:
The list of displayed devices should change and show a FIPS device.
The "enable fips" button should change its wording to "disable fips".

Additional info:
The problem is the post-processing that is applied by the RPM-build system,
which strips away information from the shared library files.
FIPS mode can only work when the signature files libfreebl3.chk and
libsoftokn3.chk matches the contents of the corresponding .so files.
Because the .so files get changed after the signing, the NSS runtime checks fail
and reject FIPS mode.

After exploring some options, we have decided to generate the .chk files on
package install in the rpm script %post step.
This requires including the "shlibsign" tool in package nss.

Comment 1 Kai Engert (:kaie) (inactive account) 2007-03-02 19:20:12 UTC
fixed in:
- nss-3.11.5-0.6.1.fc6
- nss-3.11.5-0.5.1.fc5
- nss-3.11.5-2.fc7

Comment 2 Kai Engert (:kaie) (inactive account) 2007-03-07 22:07:23 UTC
(Note this bug is for Fedora only (not for other products)).

Unfortunately the fixed Fedora RPMs still don't work.
So I'm reopening.

The problem is the nightly prelink daemon that changes the shared library *again*.

The optimal fix (proposed by Ulrich Drepper) might be: a new ELF flag, that
marks a DSO and makes it immutable, and have all file modifying applications
respect that. But this is absolutely not a short term fix.

Another option: Blacklist the shared libs in /etc/prelink.conf
But this has the disadvantages:
- we'll have to carry around these entries forever
- the file names of the blacklisted libraries might change
- we aren't sure prelink is the only application that will ever transform .so
files on disk

A third option is to use
  chattr +i
attribute to protect the files from manipulation.
This works on ext2/ext3.
- does not work on xfs/jfs filesystems

Comment 4 Wan-Teh Chang 2007-03-08 00:11:30 UTC
Another long-term solution is for NSS to be smarter when calculating
the checksum of a .so file.  It should skip the parts of a .so file
that may be modified by rpm-build (strip?) and prelink.

Ulrich, Jakub, is it possible for NSS to do that?

Comment 5 Ulrich Drepper 2007-03-08 00:23:49 UTC
Prelinking will always modify vital sections.  Otherwise it couldn't work.  So,
no, there is no meaningful checksum you can compute when the RPM is packaged. 
Every prelinking run in addition creates different results.  So, you cannot
precompute two checksums, one with and one without prelinking.

The only options are

- recompute the checksum after each prelink run

- prevent prelinking

Since I don't see how the checksum is helping security in the first place I
don't see anything particularly bad with the first option.  But since nss seems
to be dynamically loaded by firefox and thunderbird (via dlopen, correct me if
I'm wrong) I don't see anything wrong with not prelinking.  Startup of the other
programs directly using nss is likely not that performance critical.

Comment 6 Wan-Teh Chang 2007-03-08 01:50:19 UTC
You're right -- it is fine to recompute the checksum
after each prelink run.  The checksum's purpose is to
detect accidental file corruption, not malicious

NSS is used directly by a .so that is dynamically loaded
by Firefox and Thunderbird via dlopen.

Comment 7 Ulrich Drepper 2007-03-08 02:20:56 UTC
In that case I suggest to talk to Jakub next week about adding some hooks into
/etc/cron.daily/prelink to run some scripts after prelink is done.  For
instance, create /etc/prelink.after.d/ and run all the scripts in there.  Then
nss can install an appropriate script into this directory which recomputes the

Comment 8 Kai Engert (:kaie) (inactive account) 2007-03-08 05:01:09 UTC
Time A: prelink changes the FIPS library
... prelink changes more libraries
Time B: resigning happens

There will always be a period of time, between A and B, where the checksum file
mismatches the .so file - right?

What happens when a process gets started while the files do not match?

Shouldn't we avoid mismatches, in order to guarantee it will work at any given time?

Comment 9 Wan-Teh Chang 2007-03-08 15:09:41 UTC
You're right, we should avoid any period of time whe
the checksum file doesn't match the .so file.  So
preventing prelinking is the only option.

Comment 10 Bug Zapper 2008-04-04 06:24:18 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here: to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out

Comment 11 Bug Zapper 2008-05-06 19:17:36 UTC
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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