Red Hat Bugzilla – Bug 230545
Can not enable NSS FIPS mode
Last modified: 2008-05-06 15:17:37 EDT
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)
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
- Nothing happens
The list of displayed devices should change and show a FIPS device.
The "enable fips" button should change its wording to "disable fips".
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.
(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
attribute to protect the files from manipulation.
This works on ext2/ext3.
- does not work on xfs/jfs filesystems
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?
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.
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.
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
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?
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.
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
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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 http://fedoraproject.org/wiki/BugZappers
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.