449498 - Open secondary (additional) read-only system NSS database

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Kai Engert [:KaiE:]]

Fedora has started to ship an NSS database in the OS global location /etc/pki/nssdb, which contains system-wide certificates or security modules that all applications should have access to.

I think the proposal is to open that additional database automatically on NSS init time.

We'd like to do this at least on Linux, and maybe we should start with #ifdef'ed code.
We could add other platforms, too, if there is interest and a standardized location for this kind of database (with the initial version or at a later time).

Comment 1

[David Woodhouse]

Attachment: xulrunner patch to make firefox use system nssdb

It shouldn't be an additional database; the application should open sql:/etc/pki/nssdb _instead_ of its old database. The libnsssysinit.so module automatically handles opening the user's own database in ~/.pki/nssdb as an 'overlay'.

With the NSS bugs fixed as described in https://bugzilla.redhat.com/show_bug.cgi?id=603313 this works as expected; merging the old DBM database from the profile directory into the user's SQL database. If the system database isn't configured, then it just uses the DBM database as before.

Comment 2

[David Woodhouse]

Attachment: revised patch to try system db only on unix

Comment 3

[Kai Engert [:KaiE:]]

This bug was initially filed against the NSS component with the expectation to

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

David, Are you requesting that this patch be reviewed and considered for 
inclusion?  Or is this merely a "work in progress"?  

If you believe this patch is ready for submission, please request that it 
be reviewed by [e-mail]

Comment 5

[David Woodhouse]

Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

I think it's ready for inclusion. There are NSS bugs which need to be fixed -- but this part only triggers if the system NSS DB is enabled anyway; if it's not enabled you get the old behaviour.

Comment 6

[Wan-Teh Chang]

Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

Bob Relyea is the best person to review this patch.

Bob, it'd be bad if an application had to read pkcs11.txt
directly and look for "library=libnsssysinit.so".

This should be done by the NSS initialization functions.
If we have a good error code that NSS initialization functions
can return to indicate a missing pkcs11.txt unambiguously,
an application can simply try initializing NSS with
"sql:/etc/pki/nssdb", and fall back on the home/profile
directory if it gets that error code.

Comment 7

[David Woodhouse]

(In reply to comment #6)
> Bob, it'd be bad if an application had to read pkcs11.txt
> directly and look for "library=libnsssysinit.so".

Yeah, it sucks that we have to do this.

cf. https://bugzilla.mozilla.org/show_bug.cgi?id=490238#c37

I'd rather have NSS just do the right thing rather than returning an error when we attempt to open sql:/etc/pki/nssdb r/w though.

Comment 8

[Robert Relyea]

Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

Way behind on my reviews. I'm OK with this patch with the following caveats.

1) this is PSM code so Kai should have the final say since he'll have to support what goes in.
2) explicity checking for libnssysinit.so may fail in the future is we support some admin tool that replaces libnsssysinit with something that gets the nss configuration from some admin repository.

#1 is the more critical issue.

bob

Comment 9

[David Woodhouse]

Having talked to people about GNOME keyring plans at GUADEC this week, I'm a little bothered by your #2 too. I can envisage a situation where we point at a GNOME-keyring PKCS#11 module directly from /etc/pki/nssdb, instead of using libnsssysinit. (Although maybe we'd be more likely to put that in the user's pkcs11.txt instead.)

Should we make it trigger if *any* module would be loaded by the /etc/pki/nssdb/pkcs11.txt file, rather than just libnsssysinit.so ?

Comment 10

[Kai Engert [:KaiE:]]

This patch uses 
  NSS_InitWithMerge

Unless I missed something new, in my understanding, this may require multiple master password prompts. This is necessary if the old profile db uses a different password than the user's shared db in ~/.pki/nssdb

If this is true, in my understanding, we must use application assisted merging.

This document lists a proposal of how this could be done:
https://wiki.mozilla.org/PSM:UIforSharedDB

If you agree with me that application assisted merging is necessary, I believe this patch is r-

Comment 12

[Schlomo Schapiro]

Using Mozilla products in a corporate context is really inconvenient due to this issue. All our users have to individually import our CA certificate because FF and TB don't read it from the available /etc/pki/nssdb files.

Comment 13

[David Mansfield]

The derailment of this bug is caused by a requirement that has nothing to do with this bug.
  
This bug is supposed to be about using a read-only, system-wide NSS database, however the blocking issue has to do with the fact that somewhere along the line, the decision was to ALSO remove the separate per-user NSS databases used by, e.g. firefox and thunderbird (which are currently stored in profile directory) and instead making a single per-user read-write database stored at, e.g. ~/.pki/nssdb

And while I understand that this is also a desirable outcome, does it have anything to do with allowing site-wide use of TB without having users be forced to hand-configure their TB before accessing corporate mail servers protected with internal CA, which is the essence of THIS bug report?  It doesn't seem the two are actually related...

Any chance that progress could be made on this?

Comment 14

[Robert Relyea]

kai, can you switch this bug to PSM? Both the patch and the ultimate solution are PSM issues.

bob

Comment 15

[Cameron H]

Any progress on this yet? As was mentioned earlier, this can be a major inconvenience in an enterprise environment.

Comment 16

[David Woodhouse]

FWIW the trust issue has mostly been solved. Fedora for example ships p11-kit-trust.so as a replacement for NSS's libnssckbi.so. It provides all the trust roots in the place that NSS *expects* them to come from.

Comment 17

[vamega]

I'm not sure this bug has been completely fixed. I'm running Ubuntu 15.04 and it's not picking up certificates that the rest of the system is picking up (I checked that curl and wget were fetching the URL's correctly while verifying certificates).

Comment 18

[David Woodhouse]

Are you referring to my comment 16? You do need your distribution to ship p11-kit-trust.so in place of Mozilla's libnssckbi.so, so it has a consistent set of trusted CAs with the rest of the system.

Comment 19

[Stefan Fleiter (:sfleiter)]

Probably relates to bug 454036 and should be platform all

Comment 20

[David Ward]

@J.C. Jones Can you kindly undo your recent change to the status of this bug?

@David Woodhouse: p11-kit-trust.so only handles CA certificates; it does not pull in the PKCS#11 security module configuration, which is stored in the system-wide NSS database. This is required where smart cards are used (using security modules such as OpenSC, either directly or via the p11-kit-proxy security module). This was part of the issue reported with this bug.

As it stands now, the PKCS#11 module configuration still has to be manually added to every Firefox/Thunderbird profile after the application is first launched by the user and the NSS databases are created at that time. Changes to the system-wide NSS database won't propagate (for example, if the system administrator replaces the CoolKey module with OpenSC).

Comment 21

[Robert Relyea]

David, I presume you are running on Linux? If your firefox/thunderbird is build with policy enabled, you can add the line to our policy file:

name=p11-kit-proxy
library=p11-kit-proxy.so

On Fedora or RHEL 8 the policy file is in /etc/crypto-policies/back-ends/nss.config.
On RHEL7 it's in /etc/pki/nss-legacy/nss-rhel7.config

For other distributions look at the build scripts for POLICY_FILE and POLICY_PATH.

Comment 22

[J.C. Jones [:jcj] (he/they)]

David,

Let me know if Bob's advice here isn't a good resolution. Otherwise, I don't see us changing NSS' behavior to load multiple SQLite databases.