Bug 990631 - file permissions of pkcs11.txt/secmod.db must be kept when modified by NSS
file permissions of pkcs11.txt/secmod.db must be kept when modified by NSS
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss-util (Show other bugs)
6.5
Unspecified Unspecified
urgent Severity high
: rc
: ---
Assigned To: Elio Maldonado Batiz
Hubert Kario
:
Depends On:
Blocks: 993793 1002222 1087926
  Show dependency treegraph
 
Reported: 2013-07-31 11:25 EDT by Kai Engert (:kaie)
Modified: 2014-04-15 11:18 EDT (History)
9 users (show)

See Also:
Fixed In Version: nss-util-3.15.1-3.el6
Doc Type: Bug Fix
Doc Text:
Cause: NSS changed the permissions of the existing pkcs11.txt file, reverting to the strict default of 0600, even when the file previously had other permissions. Consequence: This prevented users from adding security modules to their own configuration which is accomplished via acces to the system-wide security databses. If the user has root access the system database is modified otherwise the user's own default database is the one that is modified. Fix: NSS now keeps the strict default 0600 permissions for new files while preserving the existing permissions when replacing an existing pkcs11.txt file. Result: Users can now make the necessary modifications to the nss security module database.
Story Points: ---
Clone Of:
: 1087926 (view as bug list)
Environment:
Last Closed: 2013-11-21 01:16:41 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The patch Kai has submitted upstream (3.46 KB, patch)
2013-08-21 18:00 EDT, Elio Maldonado Batiz
rrelyea: review+
Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 900067 None None None Never

  None (edit)
Description Kai Engert (:kaie) 2013-07-31 11:25:43 EDT
This report has two parts:
- A functional problem
- cosmetic issue in the same tool that should get fixed while working on
  the first part

(1)
When using
  sudo modutil -dbdir sql:/etc/pki/nssdb -add "name" -libfile "/path/pkcs11.so"

the file /etc/pki/nssdb/pkcs11.txt gets created/modified with file permission that allow only root to read the file:
  -rw-------. 1 root root 524 31. jul 15.55 /etc/pki/nssdb/pkcs11.txt

That's counterproductive, as it prevents ordinary users to read the list of globally registered modules.

(The same issue was found when using the nss-gui tool to interactively configure a new pkcs#11 module, so the cause of the problem might actually be in core NSS, not in modutil.)


(2)
When using 
  modutil -dbdir sql:path -add ... -libfile ...

to register a new module, the modutil will print this warning:

 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.

Does this warning really make sense when using a sql: path?

If not, should modutil get changed to detect the sql: prefix and avoid the warning?
Comment 1 David Jaša 2013-07-31 11:38:14 EDT
There is third issue with modutil (and it's other *util siblings probably as well): when no -dbdir is specified, it assumes old /etc/pki/nssdb instead of now-preferred shareable sql:/etc/pki/nssdb.


WRT (1) part of the description:
$ sudo strace modutil -dbdir sql:/etc/pki/nssdb/ -add "CoolKey PKCS#11 Module" -libfile /usr/lib64/pkcs11/libcoolkeypk11.so 2>&1 | grep pkcs11.txt

open("/etc/pki/nssdb/pkcs11.txt", O_RDONLY) = 3
open("/etc/pki/nssdb/pkcs11.txt", O_RDONLY) = 14
open("/etc/pki/nssdb/pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = 14
open("/etc/pki/nssdb/pkcs11.txt", O_RDONLY) = 14
unlink("/etc/pki/nssdb/pkcs11.txt")     = 0
access("/etc/pki/nssdb/pkcs11.txt", F_OK) = -1 ENOENT (No such file or directory)
rename("/etc/pki/nssdb/pkcs11.txu", "/etc/pki/nssdb/pkcs11.txt") = 0
open("/etc/pki/nssdb/pkcs11.txt", O_RDONLY) = 14
open("/etc/pki/nssdb/pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = 14

$ sudo strace -f nss-gui 2>&1 | grep pkcs11.txt
[pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDONLY) = 3
[pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDONLY) = 39
[pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = 39
[pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDONLY) = 39
[pid 10185] unlink("/etc/pki/nssdb//pkcs11.txt") = 0
[pid 10185] access("/etc/pki/nssdb//pkcs11.txt", F_OK) = -1 ENOENT (No such file or directory)
[pid 10185] rename("/etc/pki/nssdb//pkcs11.txu", "/etc/pki/nssdb//pkcs11.txt") = 0
[pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDONLY) = 39
[pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = 39
Comment 3 Elio Maldonado Batiz 2013-07-31 12:34:15 EDT
In nss.spec the relevant lines are:

Source8:          system-pkcs11.txt ### line below renames it
%{__install} -p -m 644 %{SOURCE8} $RPM_BUILD_ROOT/%{_sysconfdir}/pki/nssdb/pkcs11.txt
                   ^^^ --- read access for everyone

%config(noreplace) %verify(not md5 size mtime) %{_sysconfdir}/pki/nssdb/pkcs11.txt

They are the same as they were on rhel-6.4. Something else is going on outside of the nss.spec.

I'am looking at in fedoara, will be doing it my rhel-6.5 VM but I am seeing even in f19 the wrong persmisions. 

Using modutil I can add the coolkey module only via sudo. When I try it as mysef it fails with "modutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format." 

It doesn't make sense because I invoked the tool via
modutil -dbdir sql:/etc/pki/nssdb/ \
-add "CoolKey PKCS#11 Module" -libfile 
/usr/lib64/pkcs11/libcoolkeypk11.so

I explicitly used the sql: prefix. I bet modutil isn't aware of prefixes. Perhaps it should be. That still doesn't explain the wrong permissions which is the main subject of this bug.
Comment 4 Kai Engert (:kaie) 2013-07-31 12:56:31 EDT
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=900067 upstream for the file permissions on pkcs11.txt
Comment 5 Kai Engert (:kaie) 2013-07-31 13:00:11 EDT
Elio, I think your comment 3 might be irrelevant for this bug.

Yes, we agree the permissions are initially right, it's about permissions being changed by modutil.

Second, the modutil tool works correctly when using the sql: prefix. Of course you require sudo to change the files in /etc. Of course you'll get an error if you try to change /etc/ with your regular user account. The error message you saw is simply an incorrect error message, as modutil doesn't expect to lacking permissions for the files given.
Comment 6 Kai Engert (:kaie) 2013-07-31 13:08:34 EDT
I filed upstream bug 900086 for the cosmetic issue regarding the warning printed by modutil. It isn't blocking this work, it's just nice to have.
Comment 7 Kai Engert (:kaie) 2013-07-31 13:11:53 EDT
(In reply to David Jaša from comment #1)
> There is third issue with modutil (and it's other *util siblings probably as
> well): when no -dbdir is specified, it assumes old /etc/pki/nssdb instead of
> now-preferred shareable sql:/etc/pki/nssdb.

We can't change the behaviour of the tools in a RHEL branch.

Even though shared sql might now be prefered, there are still applications that use it, e.g. Firefox.

Until we can make the new access method the default in most applications, it might be good to keep the old default, to minimize confusion.

If we're ever going to make a change, it might be wise to require the user to explicitly specifc the access mechanism, but that also has problems because of script automation etc. Anyway, I think that's not easily doable and is a separate discussion.
Comment 8 Bob Relyea 2013-07-31 16:58:13 EDT
So we have a whole host of issues in one bug, and that makes things confusing. Some of these issues are upstream issues, others are probably local. Let me address them one at a time...


1) Permissions: In RHEL and fedora, we should always seed /etc/pki/nssdb from the spec file with an appropriate pkcs11.txt. When NSS is automatically creating the file (which means softokn in this case. modutil isn't actually doing the open), it doesn't know whether the file is a shared (among users) file or not. The correct default is 0600 for creation of this file. example: 

mkdir test
certutil -N -d test
ls -l

So this isn't a bug in modutil. We need to make sure when we put the initial seeded versions for the system files in /etc/pki/nssdb, that they have to correct permissions (which I think Elio has shown). If there are some instructions for recreating them, then we need to add the chmod a+r to those instructions..

--------------------------------------------------------------------------

2) modutil's warning. This is an upstream issue. We probably should only warn if we are using dbm. I don't consider this a serious or high priority. It actually won't be really easy to fix (the underlying details of the token are usually pretty hidden from the application. Looking at the string is not a reliable way of fixing this, someday NSS may change the default to always be sql).

---------------------------------------------------------------------------

3) modutil/certutil default. I thought the default was ~/netscape, or something. I'm OK with changing it to sql:/etc/pki/nssdb upstream, but that discussion needs to happen there. What ever happens upstream, certainly changing this default for fedora/RHEL-7 is probably a good idea.

--------------------------------------------------------------------------

> Second, the modutil tool works correctly when using the sql: prefix. Of 
> course you require sudo to change the files in /etc. Of course you'll get 
> an error if you try to change /etc/ with your regular user account. The 
> error message you saw is simply an incorrect error message, as 
> modutil doesn't expect to lacking permissions for the files given.

I'm curious if you did this experiment with nsssysinit turn on. If you did, modutil should modify the users pkcs11.txt (~/.pki/nssdb I think) just like certutil does for the .db's.


bob
Comment 9 Bob Relyea 2013-08-01 12:41:58 EDT
> Even though shared sql might now be prefered, there are still applications
> that use it, e.g. Firefox.

To be clear, I think the default David is talking about is the default for the NSS tools if no database is supplied, not what NSS opens by default if the sql: or dbm: isn't included.

In any case I agree we have to be careful about changing defaults for the tools on shipping versions of RHEL. Kai's instincts are exactly correct.....

....OTOH I doubt very seriously that there is anyone using the defaults. On RHEL-6 certutil -L does not list /etc/pki/nssdb (either dbm: or sql: ). The current default is actually ~/.netscape... still probably not a RHEL 6.5 change we should make without floating out a trail balloon or something...

--------------------------------

(BTW you can change 'whether to open dbm: or sql:' default with an environment variable. I've been running with the NSS_DEFAULT_DB_TYPE=sql for 5 years now (which actually forces Firefox and Thunderbird to use sql databases rather than dbm, just not the system sql databases)). Still again, Kai's instincts are correct. I don't run with those databases in NFS, so there may be weirdness in some environments. I don't even think we can make this kind of change in fedora or RHEL-7 yet (unfortunately. I'd like to be able to drop dbm support from RHEL-7). Clearly making this change in RHEL 6.5 is out.
Comment 10 Kai Engert (:kaie) 2013-08-01 13:36:15 EDT
There was a misunderstanding that we clarified during a phone call.

The problem is that core NSS *changes* the permissions of the existing pkcs11.txt file, *reverting* them back to the default 0600, even if the file previously had other permissions.

We agreed on the following during the call:

- if pkcs11.txt does not yet exist, we should create it as 0600

- if pkcs11.txt already exists, we must keep the permissions when modifying

As of today, our code uses a series of two commands, in order to use the permission flags, but still associate it with a FILE*:
- fd = open(name, O_CREAT|O_RDWR|O_TRUNC, 0600);
- fdopen(fd, "w+");

It's more complicated even, the existing code in nssutil_DeleteSecmodDB might sometimes erase the old file and create a new one.

I conlcude:

The correct implementation strategy is to use "stat" to obtain the existing permissions, and using them when creating the new files.
Comment 11 Kai Engert (:kaie) 2013-08-01 13:36:57 EDT
I propose to do all further technical discussion related to pkcs11.txt in the upstream bug.
Comment 12 Kai Engert (:kaie) 2013-08-01 13:42:14 EDT
Regarding the warnings printed by modutil: Based on the comments I'll remove it from this RHEL bug, but we'll still track it upstream.
Comment 13 Elio Maldonado Batiz 2013-08-21 18:00:54 EDT
Created attachment 789005 [details]
The patch Kai has submitted upstream
Comment 24 Kai Engert (:kaie) 2013-10-14 17:39:12 EDT
The patch changes nss/lib/util

The patch must be added to the nss-util package - not the nss package.
Comment 25 Kai Engert (:kaie) 2013-10-14 17:46:01 EDT
The package of this bug should be changed to nss-util.

To avoid this kind of mistake (which has happened in the past), we should consider to "rm -rf nss/lib/util" directory after unpacking the source archive.
Comment 31 errata-xmlrpc 2013-11-21 01:16:41 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1558.html

Note You need to log in before you can comment on or make changes to this bug.