Fixing NSS and p11-kit in Fedora (and beyond)

Stef Walter stefw at
Fri Dec 12 03:02:58 PST 2014

On 12.12.2014 10:48, David Woodhouse wrote:
> On Fri, 2014-12-12 at 09:22 +0100, Stef Walter wrote:
>> On 11.12.2014 10:12, David Woodhouse wrote:
>>> I'd love to have a Fedora Feature in F22 for PKCS#11, where keys+certs
>>> from installed PKCS#11 modules are expected to Just Work™ in all
>>> applications that can use certificates. Using consistent PKCS#11 URIs
>>> where appropriate. Even if we aren't ready for a Feature, I'd love to
>>> make some more progress in that direction. Obviously none of this is
>>> really Fedora-specific, but if we can get it right in Fedora (as we did
>>> for the trust stuff), other distributions can follow.
>> I believe there's an open process for proposing Fedora Features and I
>> think it's going on right now. But I agree that doing all of this in a
>> few months is a bit much to bite off, even for someone as tireless as
>> you :D
> Yeah. I'm severely tempted at least to file an overall tracker bug for
> the "feature", and file individual bugs against all the packages that
> need to be "fixed" to comply with the vision. It'll make it much easier
> to track. Any objections?

There's nothing to object to. That makes sense.

>> Note that /etc/pki/nssdb is also not completely safe on multi-user
>> systems. One user can easily lock the database and prevent any other
>> user from doing NSS crypto with that database. Correct me if I'm wrong.
> Bob knows best, but I'm not sure I recognise that problem. The database
> in /etc/pki/nssdb is read-only, so I don't think unprivileged users can
> do *anything* to screw with others' access to it.

It is possible to flock or fcntl(FD_SETLK) a file that you don't own,
and that prevents anyone else from getting an exclusive/write lock on
it. Crazy ... put it on the pile of shitty unfixable security issues
with Linux.

Simple demo with flock():

$ sudo touch /etc/test
$ flock --shared /etc/test sleep 1000 &
$ sudo flock --exclusive /etc/test echo "worked"

sqlite uses fcntl, although it does not block indefinitely on the lock.
It exits after a short timeout. So a little program like this run by a
user, can cause other NSS access to /etc/pki/nssdb/cert9.db to fail.

#include <err.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
main(void) {
	struct flock l = { .l_type = F_RDLCK, .l_whence = SEEK_SET, .l_start =
0, .l_len = 0 };
	int f = open("/etc/pki/nssdb/cert9.db", O_RDONLY, 0);
	if (f < 0)
		err(1, "open");
	if (fcntl (f, F_SETLK, &l) < 0)
		err(1, "fcntl");
	printf ("locked\n");
	sleep (100000);
	return 0;

$ sudo certutil -d sql:/etc/pki/nssdb -L
certutil: function failed: SEC_ERROR_PKCS11_GENERAL_ERROR: A PKCS #11
module returned CKR_GENERAL_ERROR, indicating that an unrecoverable
error has occurred.

At a fundamental level it appears that a database which uses advisory
locking may not be shared by different security contexts (read users).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the p11-glue mailing list