Using NSS 3.4 trunk tip, create new cert, key and secmod dbs using the command mkdir /tmp/newdb certutil -N -d /tmp/newdb Then attempt to connect to an SSL server whose cert was issued by a well known CA, whose CA cert is in nssckbi, e.g. www.microsoft.com. The command I used was strsclnt -c 2 -d /tmp/newdb -t 1 -v www.microsoft.com The expected result is that two https connections will be done. The first will do a full RSA handshake, and the second will do a restart handshake. But the actual result is strsclnt: Subject: CN=www.microsoft.com, OU=mscom, O=Microsoft, L=Redmond, ST=washington, C=US strsclnt: Issuer : OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US strsclnt: -- SSL: Server Certificate Invalid, err -8179. Peer's Certificate issuer is not recognized. strsclnt: PR_Write returned error -8179: Peer's Certificate issuer is not recognized. This has been observed on 3 different platforms. When he tested it on Linux, Ian observed that nssckbi was not being loaded. He also tried copying nssckbi into the directory where secmod.db is located, but still nssckbi was not loaded. Finally he configured secmod.db explicitly to load nssckbi, and then it worked. I believe it should not be necessary to explicitly put nssckbi into secmod.db. Further, I believe that if nssckbi is in the same directory where the other nspc and nss DLLs are located, NSS should be able to find it there and load it. That is, it should not be nececssary to copy nssckbi to the secmod.db directory to load it.
This needs to work in 3.4.
Priority: -- → P1
Target Milestone: --- → 3.4
nssckbi only gets automatically loaded when 1) it's in the appropriate directory, 2) the application openned the databases ReadWrite, and 3) a built-in module has not already been loaded In this case it gets loaded and inserted into secmod.db It also gets loaded if it is already in secmod.db The following should work: mkdir /tmp/newdb cp libnssckbi.so /tmp/newdb certutil -N -d /tmp/newdb strsclnt -c 2 -d /tmp/newdb -t 1 -v www.microsoft.com If you do the copy after the certutil -N, strsclnt won't be able to add the built-ins to the secmod.db. Question: should we attempt to load the built-ins even if we can't add them to secmod.db? We could do that by changing the if statement in nss_Init from: if ((!readOnly) && (!noModDB) && (!noCertDB) && (!noRootInit)) to if ((!noModDB) && (!noCertDB) && (!noRootInit)) bob
Assigned the bug to Bob.
Assignee: wtc → relyea
IMO, yes, we should attempt to load the builtins module even if secmod.dh is RO. Having to have the dll in the same directory where the secmod.db file lives seems to violate the idea of separating trusted code files from user-modifiable data files. In system security terms, All parts of the TCB should (potentially) be kept in a directory where the user does not have write access. Is there a way to get nssckbi loaded without copying it to the secmod.db directory and without expicitly using modutil to config it into secmod.db?? IMO, there should be.
If you can tell me how to do it. This has been the semantic since NSS 3.1. Most applications either copy the built-ins to the correct location, or explicitly load the builtins on their own. The latter gives the apps control over where they install the libraries. The problem is there was no good way to find the path for where libnssckbi.so was supposed to be. The only path we had available was the configDir path. Removing the readonly flag seems reasonable for NSS 3.4.
At Bob's suggestion, I created a secmod.db file that had the nssckbi module declared in it, without any path. That is, the file name is just "nssckbi.dll". Bob said that would find the dll in the PATH, and indeed, it did. So, I can have a single fixed secmod.db file that will work for all apps on WinCE, and that is enough for now. Lowering to P2.
Priority: P1 → P2
Should we remove the readOnly flag and close this bug? Is there anything else we need to do about this bug?
After talking with nelson, it would be possible to load nssckbi from the path if we don't find it in the configdir, but I'm worried that this would be a semantic change which could affect existing 3.x products expecting the current behaviour. I'll attach a patch for the removed flag.
Picking up nssckbi.dll from the path can be dangerous. If someone adds a different nssckbi.dll to your PATH, you will unknowingly pick it up.
Wan-Teh: Yes, that is why I'm relunctant to make it a default.
The same argument could be made for any part of NSS, no? All the software in your PATH must be "trusted", IINM.
Comment on attachment 71974 [details] [diff] [review] Load builtins even when opening read only r=wtc. Bob, have you tested this patch?
Attachment #71974 - Flags: review+
I've ran our system tests on the patch to determine it does not cause any obvious regression, but it has not been tested for the functionality it is supposed to provide.
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
The only remaining issue in this bug is the path search issue, and that seems to be a semantic change that could upset existing applications. Moving to 4.0 where we can make these kinds of semantic changes.
Target Milestone: 3.4 → 4.0
*** Bug 154736 has been marked as a duplicate of this bug. ***
Created attachment 89573 [details] [diff] [review] Patch for NSS_Init Turns out that the previous patch alone is not enough to fix the bug. NSS_Init is not loading nssckbi.dll automatically because it incorrectly passes PR_TRUE as the noRootInit argument to nss_Init. This bug was most likely introduced in NSS 3.4 Beta 1, when the noRootInit argument to nss_Init was added. This bug has been fixed on the tip (3.6).
Closing bug since the patch is checked in the tip.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Verified that the fix was checked into the tip in rev. 1.48 of nssinit.c.
Status: RESOLVED → VERIFIED
This bug has been marked fixed, but the symptom originally described is still reproducible in NSS 3.10. This is now reportedly an issue for RedHat, and has been discussed in the newsgroup. Bob/Wan-Teh, please kindly add a comment here stating what other symptom you fixed when this bug was closed. Perhaps a separate bug should have been filed for that other symptom, whatever it was, rather than marking this bug fixed. Now, perhaps a new bug should be created that restates the original issue, and this bug (128290) should be modified to describe the symptom that was fixed for NSS 3.6.
Trying to do automatic loading of libnssckbi.so in NSS would only make the redhat case worse. The problem would not only be trying to determine where libnssckbi.so is, but trying to determine the correct libnssckbi.so (32 or 64 bit). On top of that, it's looking like for a number of interesting applications, we may not want to load libnssckbi.so at all, so making NSS autoload libnssckbi is probably going the wrong way. Ideally the application should load the version of libnssckbi.so that it wants to use, and we shouldn't do any autoloading from NSS. bob
So, Bob, please add a comment here stating what symptom you fixed when this bug was resolved.
You need to log in before you can comment on or make changes to this bug.