Hide Forgot
Description of problem: It is not possible to turn on FIPS mode of NSS DB. Version-Release number of selected component (if applicable): nss-3.15.3-4.el5_10.ia64 How reproducible: 100% Steps to Reproduce: 1. modutil -fips true -dbdir /etc/pki/nssdb/ Actual results: ERROR: Unable to switch FIPS modes. Expected results: FIPS mode enabled. Additional info: There was a similar issue before, it might be unrelated but still, better to see Bug 462470. This is a regression from nss-3.14. Kudos to Ales and Hubert for pointing on this issue.
Ales, are there any other settings of the system? I cannot reproduce it neither with nss-3.15.3-4.el5_10 nor nss-3.15.3-3.el5_10.
Even in fips mode (ie. kernel booted with fips=1 parameter) it works as expected: # cat /proc/sys/crypto/fips_enabled 1 # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.10 (Tikanga) # rpm -q nss nss-3.15.3-4.el5_10 # uname -a Linux pq0-0.lab.bos.redhat.com 2.6.18-371.el5 #1 SMP Thu Sep 5 21:23:39 EDT 2013 ia64 ia64 ia64 GNU/Linux # modutil -fips false -dbdir /etc/pki/nssdb/ WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q <enter>' to abort, or <enter> to continue: FIPS mode disabled. # modutil -fips true -dbdir /etc/pki/nssdb/ WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q <enter>' to abort, or <enter> to continue: FIPS mode enabled.
(In reply to Ondrej Moriš from comment #1) > Ales, are there any other settings of the system? I cannot reproduce it > neither with nss-3.15.3-4.el5_10 nor nss-3.15.3-3.el5_10. No, it was a system provisioned using bkr workflow-tomorrow --errata 16566 --distro rhel-5.10.z --new --edit --reserve (and all tests removed manually), the test case (TC#194360) was copied over using scp and run using `make run` I had this problem on two different machines, one fully automated and one provisioned using above command.
Well, I must admit that on some systems this issue can be seen. At the time being it looks like it somehow does not depend on nss version - once you hit it with 3.15.3-4.el5_10.ia64 you also hit it with older version (I see the issue with nss-3.14.3-18.el5 for instance). Moreover, it really looks like the bug mentioned in the description (additional info), I do not know how it was actually tested but it really looks like the issue is still present. Therefore we do not consider this bug to be a regression. It would be better if someone from our nss maintainers will take a look into this on any of affected machines (please let me know and I will provide hostname and root password through a more secure channel). Or if you have any debugging suggestions on this, please share, we just see "security library: invalid arguments" and strace indicates that the difference between working and non-working versions happens after closing /usr/lib/libnssdbm3.so - in the next step the former opens /etc/pki/nssdb/cert8.db (and continues) and later does not (and terminates immediately).
Is it possible that 3.15.3-4.el5_10.ia64 corrupts the DB in some way and thus older versions then fail after the new version messed it up? not that I want this to be a regression, but....
(In reply to Ondrej Moriš from comment #6) > any debugging suggestions on this, please share, we just see "security > library: invalid arguments" and strace indicates that the difference between > working and non-working versions happens after closing > /usr/lib/libnssdbm3.so - in the next step the former opens > /etc/pki/nssdb/cert8.db (and continues) and later does not (and terminates > immediately). The way modutil switches back and forth between fips enabled and disabled is by finding the the internal module and if it is already in the mode requested it does nothing, otherwise it deletes the internal security module via SECMOD_DeleteInternalModule(internal_name) and internally in nss that triggers a call to SECMOD_AddModule(newModule). There are two versions of the internal module the fips and non=fips one and one is always active. This goes to nss-util which has a couple of functions to DeleteSecmodDB and AddSecmodDB and these are the ones that could call PORT_SetError(SEC_ERROR_INVALID_ARGS); and then only if the dbname == NULL. The contents of secomdb is touched. I would look for these calls calls in the strace. Of course, it may be another code path it is taking. I'll be online to get the password to that system.
I tried in the system that Ondrej reserved. It failed a few times. It doesn't anymore. I doungraded and updated nss so that may have something to do it. I did an strace and the failure happens after the sighed shared libraries verification. There is the suspicion of a corrupted shared library file. The shlibsign tool is used fgor signing and also for verification. I did that and all libraries were okay. /usr/lib/nss/unsupported-tools/shlibsign \ -V -i /usr/lib/libfreebl3.so -d /root/.pki/nssdb /usr/lib/nss/unsupported-tools/shlibsign \ -V -i /usr/lib/libsoftokn3.so -d /root/.pki/nssdb /usr/lib/nss/unsupported-tools/shlibsign \ -V -i /usr/lib/libnssdbm3.so -d /root/.pki/nssdb They all passed. I can switch to fips and back in this system. /usr/lib/nss/unsupported-tools/shlibsign -H will show a brief help Could someone try the above commands above in system that is failing?
(In reply to Elio Maldonado Batiz from comment #9) > I did an strace and the failure happens after the sighed shared libraries > verification. There is the suspicion of a corrupted shared library file. The > shlibsign tool is used fgor signing and also for verification. I did that > and all libraries were okay. Interesting, I definitely saw this problem a long time ago: * http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg09307.html Still I am wondering how can it get corrupted? And why on ia64 only? > Could someone try the above commands above in system that is failing? I will try and let you know.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Ondrej, any update here? Is this a nss bug or the problem with the system running the test?
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
(In reply to Karel Srot from comment #12) > Ondrej, any update here? Is this a nss bug or the problem with the system > running the test? Most likely it was problem with the system corrupting nss db. It is too late to do further analysis, the impact of this issue should be rather marginal.