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.
fixed in: - nss-3.11.5-0.6.1.fc6 - nss-3.11.5-0.5.1.fc5 - nss-3.11.5-2.fc7
(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
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 tampering. 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 checksum.
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. 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
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.