Bug 230545
| Summary: | Can not enable NSS FIPS mode | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kai Engert (:kaie) (inactive account) <kengert> |
| Component: | nss | Assignee: | Kai Engert (:kaie) (inactive account) <kengert> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6 | CC: | ckannan, drepper, jakub, rrelyea, triage, wtc |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | bzcl34nup | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-05-06 19:17:37 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Kai Engert (:kaie) (inactive account)
2007-03-01 13:04:57 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 (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. |