Bug 504949

If you don't care about certification you can just remove the blacklisting.  There should be a way to make this permanent.  That's something you have to bring up with the nss maintainer.

Yeah, ideally the blacklisting wouldn't be present in nss package, but only in a special package installed for fips conformance.

(In reply to comment #2)
> Yeah, ideally the blacklisting wouldn't be present in nss package, but only in
> a special package installed for fips conformance.  

The trouble with your proposal is: Once prelink touched it, you can't undo it without re-installing nss.

Should a user decide to need FIPS, and install your fips-conformance package, it's probably too late already.

I don't have a good idea to get this done.
I think the fips protection needs to be done by default, and users can have the choice to disable it (by removing /etc/prelink.conf.d/nss-prelink.conf ). This is a config change, not a package change, IMHO.

I'd like to assign this nss packaging bug to Elio.

Created attachment 348387 [details]
prelink-freebl3-failures

List of libraries/binaries that can't be prelinked because of the blacklist on my box.

I don't understand the comment about need to reinstall nss package, just do
/usr/sbin/prelink -u /%{_lib}/libfreebl3.so in fips-conformance's %post (or %pre?).  That will return to bitwise identical library with the one from rpm.

(In reply to comment #4)
> 
> just do
> /usr/sbin/prelink -u /%{_lib}/libfreebl3.so in fips-conformance's %post (or
> %pre?).  That will return to bitwise identical library with the one from rpm.  

I wasn't aware of this solution, thanks for explaining!

Any progress with this?
This is quite important, even very large programs like OOo can't be prelinked because of this.

Kai has brought this to my attention and I'll be working on this as soon as I clear some urgent tasks off my plate.

We can't fix this my removing the blacklist.

FIPS is feature in the browser, independent of any certifications. If the blacklist is removed from NSS, it will break any user that has FIPS set in his browser.

There are really only 2 solutions: 1) remove the black list, but teach prelink how to regenerate .chk files (there's a tool shipped with NSS that can do this, or 2) dynamically load libfreebl.so from libcrypt.so.

bob

I don't buy this.  There must be 3), change the browser that if fips-conformance package isn't installed (the browser could instead check for presence of certain files like the *.chk ones) and user tries to enable FIPS mode, he'll get an error in the browser telling him that fips-conformance needs to be installed and how to do that.
1) prelink as a tool certainly shouldn't do that, though perhaps we could discuss having optional hooks sources from /etc/cron.daily/prelink if something actually changed.  But that means extra time during prelinking, payed by everybody, when 99.99% of users never enable FIPS mode.
2) would be even more costly.
3) means time is only spent when somebody actually enables FIPS mode.

NSS FIPs support is a LONG TERM FEATURE of NSS that is 1) independent of any fips-comformance package, and 2) had been available is is already configured for existing users of NSS.

Any user of Firefox can (and several do) turn on FIPS mode. In many cases it's already on. If he then upgrades just NSS, his browser will blow up as soon as prelink munges either freebl or softoken. We CANNOT remove the blacklist from NSS unless there is we know that prelink can regenerate the .chk files.

It's fine for prelink to continue to work the way it does, but we must then continue to blacklist freebl and softoken. This is fundamental NSS. Of course in that case, we need to dlopen freebl from libcrypt instead of direct linking. libcrypt is the only library that direct links with either freebl or softoken. I suspect that is the correct fix for this problem.

bob

Why does FIPS mode require this special checksum file for nss, but not glibc or the browser itself?

Why can't the checksum verification code take the prelinking into account (like rpm -V does)?

FIPS 140 validated cryptographic modules are required to do a self-integrity check when running on FIPS mode. Neither glibc nor the browser have cryptographic implementations, they just call NSS.

But why can't the integrity check un-prelink the file first?

It's a runtime check requires whenever the libraries are initialized (part of the FIPS standard). It also has to be cross platform as the NSS libraries are cross platform.

As per Bob's guidance in Comment #10 I am reassigning this bug with the request that libcrypt link with with freebl dynamically.

Bob is wrong.  It makes absolutely no sense to make arguments based on FIPS if the system isn't configured to place restrictions on the user.

Specifically, if firefox is running in a unlimited environment there is no value the NSS certification adds.  Specifically, the remote site cannot deduce anything from the fact that the local firefox is compiled with and using a certified NSS.  The local user can work around any testing by attaching db and fake whatever is wanted.

So, *definitely* move the move the certification part into a separate RPM for systems which are interested in certificates.  The normal desktop machine will not want this.

We are not talking about certifications here. We are talking about a valid mode customers put their browser in and NSS supports. Not including the .chk file will break these user (we know this, anytime FIPS mode breaks on FF in Fedora we hear about it).

We cannot break those customers. One of the following must happen:
1) either we have a way to regenerate check files in the prelink step, or
2) users of libfreebl that do not want prelink to be disabled for them must dlopen it. 

I don't care which.

bob

(In reply to comment #17)
> We are talking about a valid mode
> customers put their browser in and NSS supports.

What does this mean exactly?

 
> We cannot break those customers. One of the following must happen:
> 1) either we have a way to regenerate check files in the prelink step, or
> 2) users of libfreebl that do not want prelink to be disabled for them must
> dlopen it. 

3) don't allow this special mode to be used unless the FIPS packages are installed

The latter is IMO the only thing that makes any sense.  Unless the system is wanted to be in a secure mode nothing the .chk file provides means anything.

> > We are talking about a valid mode
> > customers put their browser in and NSS supports.
> 
> What does this mean exactly?

For well over 10 years, users have been able to turn on FIPS mode in the Browser. Turning on this mode causes certain behavioral changes needed for FIPS validation, but may be desired for it's own sake (like requiring authentication before doing any crypto, for instance). 

This mode was available in early Netscape and Mozilla products, right up until today. Users may have turned it on sometime in the past. They should not have their application break because a new version of NSS has been installed.

These user's will rightly write bugs against us. (and have in the past whenever this  breaks).

> We cannot break those customers. One of the following must happen:
> 1) either we have a way to regenerate check files in the prelink step, or
> 2) users of libfreebl that do not want prelink to be disabled for them must
> dlopen it. 

3) don't allow this special mode to be used unless the FIPS packages are
installed

3 is not acceptable for NSS. The FIPS packages is something new for other toolkits. NSS customers have never needed them before, nor should they continue to need them to get the semantics they are used to getting. 3 is only acceptable if we add a dependency on that package for libfreebl -- but I see no advantage on doing so.

Please do not confuse the solution that openSSL, which does not have a long history of supporting this, from a solution acceptable for NSS or it's users.

bob

(In reply to comment #19)
> 3) don't allow this special mode to be used unless the FIPS packages are
> installed
> 
> 3 is not acceptable for NSS. The FIPS packages is something new for other
> toolkits. NSS customers have never needed them before, nor should they continue
> to need them to get the semantics they are used to getting. 3 is only
> acceptable if we add a dependency on that package for libfreebl -- but I see no
> advantage on doing so.

Of course we wouldn't add any explicit dependency.  That's defeating the purpose.

By default, even with firefox installed, no FIPS mode should be needed.  I don't see any reason to not require something new from the minute number of people who use the FIPS mode in firefox.  This most definitely make up but a tiny tiny fraction of all the Fedora users, irrelevant in the bigger picture.  Don't forget that, Bob.  Especially since the security they hope to get from enabling the FIPS mode is a complete illusion (as said before, you can attach gdb and fake whatever result you want).


> Please do not confuse the solution that openSSL, which does not have a long
> history of supporting this, from a solution acceptable for NSS or it's users.

And you don't forget what I said above: minute numbers and complete incomplete protection.  This cannot justify inconveniencing millions of other people.


It can be well documented that the FIPS mode in firefox needs preparation and the code to turn it on could test for this.  Or a firefox meta-package for the FIPS-enabled version which requires freebl package with the signature.

Yeah, or as said earlier, just pop up a warning box when user attempts to enable FIPS mode in firefox when the FIPS extra package with the signature files isn't installed, telling the user what needs to be installed and how to do it for that mode.

Note that by making libfreebl unprelinkable by default you are slowing startup of programs for almost all users of Fedora, anybody starting say OpenOffice.org will suffer just because firefox has some weird useless mode almost nobody uses.

I don't like the idea to have something in Firefox. It seems wrong to have a cross platform user level application deal with installing operating system level packages.

In addition, Firefox users are already using FIPS. They enabled it in the past. When they upgrade to a new OS version, or simply keep their home directory, they will get a failure when accessing crypto features (because loading the crypto module fails).

This means, support for this reminder would have to live even outside the security code area of Firefox. I'm not sure we can convince upstream to have such a reminder in their general core code. And how will we detect at the Firefox level that the cause of crypto failure is the missing FIPS operating system package? This feels like the wrong place to me.

If you propose that we introduce this using a patch at the Red Hat packaging level, then please consider:
- it's not just Firefox, it's any Mozilla based application (at least Thunderbird, but possibly other's)
- our patch would live outside the core code, and therefore would not get the upstream localization loving

I hope we can come up with some agreeable compromise.

I've been thinking, what about a question during installation?
By default, on upgrade, we should install the FIPS stuff to keep compatibility.
In my personal opinion, it should even get installed by default.

On new installations, when a user makes the decision "don't want fips" during installation, then we could enable prelinking systemwide.

I don't understand why nobody has yet answered Bob's proposal to always open freebl using dlopen.

Another idea:

We enhance prelink with the ability to run a script after modifying a file.

In order to minimize the changes required to prelink, we store this information completely outside of prelink.

Example, in addition to
/usr/lib/libfreebl3.so
/usr/lib/libfreebl3.chk

the NSS* package also ships file 
/usr/lib/libfreebl3.so.afterprelink.sh

We teach prelink to look for files with .afterprelink.sh
If found, after prelink touches a lib, it executes this script.

In the script, we do the magic to recreate the .chk file.

One more idea:

Have prelink store its optimized output in a separate file, e.g. libfreebl3.so.prelinked

When the loader attempts to load libfreebl3.so, have it read the separate file with the optimization information and use it.

Using a separate filename for prelinked files is completely unacceptable.  Filenames are just strings.  They cannot be changed.  Also, we would never want to pollute the system with two copies of every DSO.

Get all the changes to prelink etc out of your head.  It is NSS which introduces problems.  Therefore it has to fix it.

I don't suggest that firefox itself handles the installation of the RPM.  There is this PackageKit stuff.  With a bit of glue in firefox it can handle everything else.

Re using dlopen: this creates additional problems.  What happens if the dlopen goes wrong?  Or the dlsym?  These error are handled now before code is executed.  With dlopen the error can be recognized very late and this can create huge problems.

> Get all the changes to prelink etc out of your head.  It is NSS which
> introduces problems.  Therefore it has to fix it.

Let's be crystal clear... NSS did *NOT* introduce the problem.
The NSS code has been working for 10+ years.
Prelink broke NSS with this was the only mitigation given.
This mitigation has been working for 2+ years. It's how NSS ships today on RHEL and how NSS has shipped in Fedora since at least F7. NSS has not changed.

The problem is in the glibc usage of freebl (which is non-standard a usage of NSS we allowed to help meet the needs of glibc). It is unfortunate we did not forsee this issue at the time, but *BREAKING* NSS to fix this is not the solution.

I think there are some misconseptions here. This was not caused by the massive FIPS validation of the rest of the crypto libraries. NSS was not part of that mass validation because NSS has already been validated. 

Ulrich, if you want us to provide a different API with will automatically load freebl on the fly for you, we can talk about it, but asking NSS to break everyone else for this is a non-starter. I am open to any other solution you propose, however, including giving you your own private freebl library.

> Re using dlopen: this creates additional problems.  What happens if the dlopen
> goes wrong?  Or the dlsym?  These error are handled now before code is
> executed.  With dlopen the error can be recognized very late and this can
> create huge problems.  

Same thing that happens if NSSLOW_Init() for NSSLOWHASH_NewContext() fail. dlload and dlsym has to happen before these 2 functions are called.

The likelihood of these failing are pretty low, and in the cases they would fail the glibcrypt wouldn't even load (which seems to cause more problems).

(In reply to comment #27)
> Same thing that happens if NSSLOW_Init() for NSSLOWHASH_NewContext() fail.
> dlload and dlsym has to happen before these 2 functions are called.

No, only in the case when FIPS is enabled.  There is no reason to fail in case this is not the case.  We could then use the old implementation.  But this would violate the FIPS requirements since the old implementation is kept around and is (transparently) used.

It is NSS that's causing the problems and it has to fix them.  There is absolutely no reason to prevent the prelinking in case there is no interest in FIPS certification which is 99.99% of the time.

> No, only in the case when FIPS is enabled.

Not true... NSSLOWHASH_NewContext() could fail for many reasons, including inability to malloc memory.

> It is NSS that's causing the problems and it has to fix them. 

This is fundamentally NOT TRUE. NSS is functioning exactly as designed and has been for a decade now.

It is absolutely unacceptable to break NSS in the way you are requesting. I have presented several other options. If they are unacceptable, I'm willing to look at others, I am willing to create a glue layer that does the load library itself to decouple things. I'm willing to look at other solutions. I will not support breaking my customers and users, however.


> There is
> absolutely no reason to prevent the prelinking in case there is no interest in
> FIPS certification which is 99.99% of the time.  

This is also false for the NSS user. While FIPS is a minority, it is a much larger and vocal minority. I reguarly get bugs written against NSS when things do not work in FIPS mode. Real people use this mode in NSS who do not necesarily load the entire FIPS packages for the other toolkits.

bob

As the vocal minority is punishing the majority of users for so long, I believe prelink should just start ignore /etc/prelink.conf.d/nss-softokn-prelink.conf,
I don't see this moving in the right direction.

As the purpose of the FIPS checking requirement is just to prevent accidental changes rather than intentional (it is so lame when it doesn't check the dynamic linker etc. that it really can't even pretend to do any checking for intentional changes), why hasn't NSS been changed to just spawn prelink -y on the library and checksum its output instead of checking the library directly?  NSS had years to do that...  prelink isn't verified that it hasn't been intentionally modified, sure, but ld.so isn't either, so it isn't a significant difference.

Please, change NSS to do this ASAP for RHEL6/f13 (I can help with the change if needed), or I'll change prelink to ignore the blacklisting.

(In reply to comment #30)
> Please, change NSS to do this ASAP for RHEL6/f13 (I can help with the change if
> needed), or I'll change prelink to ignore the blacklisting.    

Jakub, as much as I agree with your assessment of the worth of FIPS checking, threatening a unilateral change to the distribution is pretty unprofessional.  What will be next?  Can Bob say, "Change prelink to regenerate the chk files or I'll add a scriptlet to NSS that does 'rpm -e prelink'"?

I don't quite understand. If 'rpm -V' can happily verify prelinked files, why can't NSS do the same when it's trying to verify its libraries?

That is indeed the current proposal.  The objection (comment #14) is that it requires Fedora-specific code, but I think that's a much lesser evil than continuing to prevent prelinking of many applications for all Fedora users.

For reference, here is the NSS FIPS verification code (line numbers may rot):

http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/shvfy.c#106

And here is the fipscheck code used by Fedora's OpenSSH, which calls prelink:

https://fedorahosted.org/fipscheck/browser/src/filehmac.c#L162

It is not Fedora-specific, rather Linux specific (most distros ship prelink).
You can very well guard it with #ifdef __linux__ (plus the access check on /usr/sbin/prelink).

At the very least, can the nss-softokn packages stop overwriting /etc/prelink.conf.d/nss-softokn-prelink.conf, and instead generate an .rpmnew file when a user has modified a conf file?
If a user has modified the .conf file, there's usually a reason for it.

That, at least, should be doable in the installer without requiring cooperation upstreams.

In either case -- linux or fedora, it's not cross platform. NSS is not only supported on Linux, but also other platforms as well (including (shudder) Windows).

Adding linux specific code here would probably be acceptible, except the time frame for modifying FIPS code is such that it won't fix our immediate problem.

The real problem here is we have other system inflexibilities.  NSS does have a way of regenerating the check files, it also, by default, loads the offending libraries dynamically so that the lack of prelink does not affect other libraries that use it.

The problems are 1) to date, there seems to be no way to get prelink to regenerate those files when it does it's work it would solve not only the NSS issue but others as well, and 2) despite NSS's careful isolation of the affected libraries as loadable libraries, libcrypt links directly with them.

One other compromise would be for libcrypt to link with a copy for libfreebl, and not the same libfreebl that NSS in general uses. In that case I see no problem with only marking that special libcrypt version as 'no-prelink' if the system fips package is installed. I agree that anyone wanting to run libcrypt in FIPS mode would install those packages.

libcrypt started linking against libfreebl because of the crypto consolidation requirements that everything unites on NSS as the only one true crypto implementation.  libcrypt used to (and if configured otherwise still does) contain all the md5/sha256/sha512 code itself.

So, please do start with the change to run prelink in the verification code, if you don't start with that now, of course the time frame will be infinite.

(In reply to comment #36)
> except the time
> frame for modifying FIPS code is such that it won't fix our immediate problem.

I forgot about that.  :(

Here is a summary of the six(!) proposed solutions for making NSS FIPS mode work on a system with prelink and their drawbacks.

1. The status quo: libcrypt links directly to libfreebl, which is blacklisted from prelinking.
  - Prevents many applications from being prelinked, slowing their dynamic linking for all users.  See:

rpm -q --whatrequires 'libcrypt.so.1('{,GLIBC_2.2.5}')(64bit)'

2. Blacklist libfreebl only if a FIPS conformance package is installed (comment #2).
  - FIPS mode users need to be warned that NSS will not work until they install the package (comment #20).  Mozilla applications might need to show a warning and launch PackageKit, etc. (comment #25).
  - After they install the package, dynamic linking of many applications is slowed.

3. Have libcrypt use a special copy of libfreebl that is blacklisted only if a FIPS conformance package is installed (comment #36).
  - A smaller population of users who want to use libcrypt in FIPS mode need to be advised to install the package.
  - After they install the package, dynamic linking of many applications is slowed.
  - Duplicates a system library, but probably would not violate the packaging guidelines because both copies come from the same package (c.f. /lib/libc.so.6 and /lib/i686/nosegneg/libc.so.6).

4. Change libcrypt to dlopen libfreebl, so that libcrypt and clients can be prelinked (comment #8).
  - Some performance penalty for the dlopen/dlsym (7 symbols) the first time an application calls a libcrypt function, for all users (comment #9).

5. Add hook support to prelink, and have NSS install a hook that regenerates the chk files (comment #9).
  - Extra work to be done at prelink time for all users (comment #9), but it probably isn't a big deal because prelink is a background job.
  - Dynamically regenerating chk files on client systems would make an already weak integrity check even weaker.

6. Change the NSS FIPS verification code to call "prelink --verify", like fipscheck and RPM do (comment #11).
  - Some performance penalty when libfreebl loads if FIPS mode is enabled, same as with OpenSSL.
  - Requires Linux-specific code in NSS (comment #14).
  - Requires changing FIPS-validated code (comment #36).

Perhaps we could have a fair discussion of the options without each side exaggerating the drawbacks of the other side's proposals.  It might be worth actually running performance tests before claiming that one penalty is bigger than another.

I'm OK with 3-5. 

I'm also OK 6 (or some form of that) as a long term solution, probably doesn't solve our immediate problem.

I think everyone agrees that 1 is not an option or this bug would have been closed WONTFIX long ago.

I'm willing to hear other options as well.

bob

Two more solutions I thought of:

7. #3, but the FIPS conformance package additionally changes libcrypt to dlopen libfreebl as in #4.  This way, users who want libcrypt in FIPS mode would get the modest penalty of #4 rather than the huge penalty of #1.

8. Enhance prelink to prelink each library except for its actual references to blacklisted libraries, instead of disqualifying all the transitive dependents of a blacklisted library from prelinking.  (I would be surprised if this isn't possible, given that dlopen works and has essentially the same effect.)  The performance penalty would be somewhat less than #4 depending on the cost of dlopen compared to direct linkage and non-prelinked symbol resolution each way.  This would make it feasible to blacklist libraries that use the Fedora fipscheck and remove the "prelink -y" code there too if desired.

8. is not possible.  If a library is not prelinked and can't be modified at all, then ld.so when loading the library has no way to know whether it is looking at the library that was seen at prelink time, or a newer/older version thereof, therefore it can't assume anything about it and thus all prelink collected info needs to be invalidated.

For 7., how do you propose to change libcrypt?  Install a new version of the package, ensure it is preferred over the standard libcrypt?  Having 2 different libfreebl's in the system is against the all crypto should start using the one true crypto implementation requirements.  If we drop that requirement, it would be much better if libcrypt stopped using libfreebl altogether and started to use its own md5/sha256/sha512 implementation.

4. the price is roughly 100usec per process that calls any libcrypt functions.

For 5., the important question is how fast the regeneration would be?  People already complain loudly how slow the prelinking/reprelinking process is (and lots of work has been done to make it faster), if this would slow it down considerably, it would be really bad.  And the argument about making the check weaker of course applies.

For 6., could you please give details?  What code exactly is certified, is it the binary that is certified or the source (I believe at least in Fedora libfreebl*.so is built from source), when will next recertification happen?
If the source, what all files are covered (and what can be changed without invalidating the certification)?  The unprelinking on the fly can be e.g. very well be started just from PR_Open/PR_Close (if the filename argument matches libfreebl*.so's path, then spawn prelink -y using popen if it exists, otherwise just do the normal open).  I see e.g. stubs.c has been modified in June 2009, ec.c in August 2009.  Has the last certification happened after that date?

Re #8: Please pardon my ignorance, but I still don't understand why the following approach would not work:

- Prelink ignores DT_NEEDED entries that point to blacklisted (or, for that matter, nonexistent) libraries.  As a result, libcrypt will have apparently undefined references; prelink leaves them alone.
- At runtime, the dynamic linker resolves the references to libfreebl using the slow path for non-prelinked code, the same as dlsym would if libfreebl were dlopened.
- In general (though it shouldn't happen with libfreebl), there is a possibility not present with dlopen that the needed library will override symbols from other prelinked libraries in the global scope.  Handle this the same way LD_PRELOAD is handled.

libfreebl is not examined at prelink time, so no assumptions are made about whether it might be modified before runtime.

Re #7: I guess there would be libcrypt and libcrypt-fips packages, and the glibc package would require one of the two.  I don't think this would compromise the goal of "one true crypto implementation".  The one true implementation is NSS libfreebl; we would just install two byte-for-byte identical copies of it and then prelink one of them.

The questions about #5 and #6 are for Bob.

I've changed prelink recently (starting with 0.4.3) to allow
prelink -u -o - /lib/libfreebl3.so
to output undo on stdout where the library when in fips strict mode can checksum it.  Eventually prelink might add a library which could do a similar thing.
For the accidental tamperation check rather than intentional tamperation prelink -u is more than enough, prelink -y isn't needed.
prelink -u -o - <library> can be run by any user who has read permissions to the library.

(In reply to comment #43)
> For the accidental tamperation check rather than intentional tamperation
> prelink -u is more than enough, prelink -y isn't needed.

I think "prelink -y" would be better.  I don't know the precise FIPS requirements, but it might be wise to play along with their fantasy that a stronger integrity check here makes the system more secure.

In any case, NSS and Fedora fipscheck should do the same thing.

The check is for accidental corruption. (which is why we call them .chk files rather than .sig files, even though they are dsa signatures). An attacker can trivially regenerate new ones. (not to meantion, the attacker could patch the self-check itself if he's purposefully modifying the code.

NSS is checking the on disk image based on the what the OS told us what it loaded, not the in memory image (which the loader could mangle on any load instance). It looks like I have someone who will pick up the bill for the revalidation. Basically option 6 is now implemented (but needs and update to prelink, which is also implemented -- thanks Jarub). They just need to wind their way through the F13 and F12 update processes.

bob

nss-softokn-3.12.4-16.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-16.fc13

nss-softokn-3.12.4-16.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-16.fc12

I had a brief look at the nss-softokn patch and found some buglets.  In particular, it calls in vfork child functions that aren't allowed in vfork children.
POSIX 2003 says on this:
The vfork() function shall be equivalent to fork(), except that the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit() or one of the exec family of functions.

close, dup2 and execv are ok, the rest (mainly strdup and PORT_NewArray, both involving malloc calls, certainly do modify the global state a lot) is not.
If you don't use fork, but vfork, you should do the command and argv initialization/preparation before calling vfork (and, to avoid memory leaks,
probably remember pointers to that somewhere and free after waitpid finishes in bl_CloseUnPrelink).  At least in Linux, the vfork child shares the address space with the parent until it calls execv.  If other threads from the parent are running simultaneously, this could die horribly, otherwise it will be probably just a memory leak, but could be worse.

Oh, and please call _exit instead of exit at the end of vfork child to avoid running atexit handlers there.

nss-softokn-3.12.4-16.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss-softokn'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-16.fc12

nss-softokn-3.12.4-16.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss-softokn'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-16.fc13

Created attachment 407647 [details]
New patch

Updated patch that fixes that issues pointed out by Jakub as well as:

close the read pipe in the client.
don't do the waitpid when closing in the case that prelink is not installed.
use the correct NSPR import function for the pipe file descriptor. (This didn't appear to affect the functionality current functionality, but the NSPR FD was probably marked wrong internally).

bob

nss-softokn-3.12.4-17.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-17.fc12

nss-softokn-3.12.4-17.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-17.fc13

nss-softokn-3.12.4-17.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss-softokn'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-17.fc12

nss-softokn-3.12.4-17.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss-softokn'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-17.fc13

nss-softokn-3.12.4-17.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

nss-softokn-3.12.4-17.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Thanks, you have broken pam on my F12. See bug #590269.

Apparently Linus Torvalds was bitten by this as well: bug #590199. The way to
trigger the problem is to run a kernel with CONFIG_CRYPTO_FIPS=n.

(In reply to comment #43)
> I've changed prelink recently (starting with 0.4.3) to allow
> prelink -u -o - /lib/libfreebl3.so
> to output undo on stdout where the library when in fips strict mode can
> checksum it.  Eventually prelink might add a library which could do a similar
> thing.

This is the problem... what happens with systems that have prelink < 0.4.3 like current Fedora 12? Everything goes to hell, and '-' files are created.

At the very least nss-softokn-3.12.4-15 should have a dependency on prelink 0.4.3.

The fact that FIPS breaks F12 systems and nobody noticed (except people running kernels with CONFIG_CRYPTO_FIPS=n), says that perhaps Bob was caring to much about that hypothetical 1% of users.

(In reply to comment #60)
IWe do have requirement of prelink 0.4.2 which is expressd as conflict line. 
It is my fault.  The the line  says:
Conflicts:        Prelink < 0.4.3
where it should have been:
Conflicts:        prelink < 0.4.3
A scratch is build is coming soon.

@Elio I hope prelink 0.4.3 is coming soon to F12 as well. I don't see the point of making 99.9% of users suffer because of FIPS silliness.

(In reply to comment #63) I'm sure Jakub will be releasing prelink 0.4.3 very soon, specially after today's incident. The scratch build with my fix is now http://koji.fedoraproject.org/koji/taskinfo?taskID=2174621
Goota setup a VM to test it, you are welcome to it as well.

I tested the scratch build at
http://koji.fedoraproject.org/koji/tasks?owner=emaldonado&state=closed&view=tree&method=all&order=-completion_time

My test systen has
[root@fedora12devel Downloads]# rpm -qa | grep ^nss-softokn
nss-softokn-3.12.4-10.fc12.x86_64
nss-softokn-freebl-3.12.4-17.fc12.x86_64
and
[root@fedora12devel Downloads]# rpm -qa | grep ^prelink
prelink-0.4.2-4.fc12.x86_64

I download the build and my attempt to update gives me:
Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit
Setting up Local Package Process
Examining nss-softokn-3.12.4-18.fc12.x86_64.rpm: nss-softokn-3.12.4-18.fc12.x86_64
Marking nss-softokn-3.12.4-18.fc12.x86_64.rpm as an update to nss-softokn-3.12.4-10.fc12.x86_64
Found 35 installed debuginfo package(s)
Examining nss-softokn-freebl-3.12.4-18.fc12.x86_64.rpm: nss-softokn-freebl-3.12.4-18.fc12.x86_64
Marking nss-softokn-freebl-3.12.4-18.fc12.x86_64.rpm as an update to nss-softokn-freebl-3.12.4-17.fc12.x86_64
Resolving Dependencies
--> Running transaction check
---> Package nss-softokn.x86_64 0:3.12.4-18.fc12 set to be updated
---> Package nss-softokn-freebl.x86_64 0:3.12.4-18.fc12 set to be updated
--> Processing Conflict: nss-softokn-freebl-3.12.4-18.fc12.x86_64 conflicts prelink < 0.4.3
--> Finished Dependency Resolution
Error: nss-softokn-freebl conflicts with prelink
 ---- two more lines skipped ---

This is what we want, nss-softokn won't be updated until prelink reaches 0.4.3.

@Elio forget about fixing FIPS, nobody cares about it.

We, the users, want CONFIG_CRYPTO_FIPS=n to work properly, fix that first, ASAP: all you need to do is push my package.

prelink-0.4.3-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/prelink-0.4.3-2.fc12

(In reply to comment #67)
Please give karma points to 
http://admin.fedoraproject.org/updates/prelink-0.4.3-2.fc12
I need to push
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-19.fc12
out to stable soon so we get Fernados's fix to Bug 590199 out.

(In reply to comment #68) Ooops, Felipe's patch.

prelink-0.4.3-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Is there anything else to be done in this bug?  I thought all the regressions resulting from the automatic un-prelink for the FIPS check had been fixed.

> Is there anything else to be done in this bug? 

I don't think so, the bug is in modified state.