Bug 230545 - Can not enable NSS FIPS mode
Can not enable NSS FIPS mode
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nss (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kai Engert (:kaie)
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-01 08:04 EST by Kai Engert (:kaie)
Modified: 2008-05-06 15:17 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 15:17:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kai Engert (:kaie) 2007-03-01 08:04:57 EST
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
mode)

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) 2007-03-02 14:20:12 EST
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) 2007-03-07 17:07:23 EST
(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.
Disadvantage:
- does not work on xfs/jfs filesystems

Comment 4 Wan-Teh Chang 2007-03-07 19:11:30 EST
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-07 19:23:49 EST
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-07 20:50:19 EST
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
tampering.

NSS is used directly by a .so that is dynamically loaded
by Firefox and Thunderbird via dlopen.
Comment 7 Ulrich Drepper 2007-03-07 21:20:56 EST
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
checksum.
Comment 8 Kai Engert (:kaie) 2007-03-08 00:01:09 EST
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 10:09:41 EST
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 02:24:18 EDT
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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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
Comment 11 Bug Zapper 2008-05-06 15:17:36 EDT
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.