Re: [bulk] PKCS#11 platform integration

[Wouter Verhelst]

On 08-05-15 14:38, David Woodhouse wrote:
> Bug 248722¹ has been open since 2004 requesting a system-wide
> configuration for PKCS#11 modules. At the time, such a thing didn't
> exist.
>
> These days it does. Modern systems ship with p11-kit², which exists
> precisely to fill that gap and provide "a standard discoverable
> configuration for installed PKCS#11 modules."

As an additional data point, I'd like to point out that as a PKCS#11
_provider_, having a system-wide PKCS#11 registry would avoid ugliness
like https://addons.mozilla.org/en-US/firefox/addon/belgium-eid/; the
sole reason for which this extension exists is that if we ship it
together with our PKCS#11, we don't have to include instructions that
tell people to click 10+ times¹ just to configure their browser so they
can do their tax declaration ("But I've just installed it!"). As it is,
the extension is the only way we can do all of that, but it causes a lot
of confusion (people who believe it will work if they just install the
extension from addons.mozilla.org without the PKCS#11 module, and
similar things).

In light of that, it would be great if firefox/libnss were to allow
configuration of PKCS#11 modules externally -- not just on Linux, but on
OSX and Windows too. From where I'm standing, it's perfectly fine if
there's a "did you install this" kind of question on the next firefox
start, as long as a process external to the browser can install such a
module.

Regards,

¹ = -> preferences -> advanced -> certificates -> security devices ->
load -> browse -> open -> ok -> ok -> close; that's 11 by my count (and
then you haven't selected the file yet).

--
Wouter Verhelst

[Wouter Verhelst]

On 08-05-15 15:09, David Woodhouse wrote:

> On Fri, 2015-05-08 at 14:58 +0200, Wouter Verhelst wrote:
>> In light of that, it would be great if firefox/libnss were to allow
>> configuration of PKCS#11 modules externally -- not just on Linux,
>> but on OSX and Windows too.
>

> Well, p11-kit does build on OSX and Windows too but it doesn't have
> the same status there. On Linux distributions it *is* the platform's
> mechanism of choice for configuring PKCS#11 tokens. NSS needs to
> support it if it wants to integrate with the platform properly.
>
> On OSX and Windows, p11-kit is just some third-party software.

Which would mean that if this gets to be "the way to do it", we don't
fix the problem on those platforms -- instead, we just move it from
"install an individual PKCS#11 module" to "install p11-kit".

> But then again, isn't PKCS#11 itself an impostor on those platforms
> anyway?

Yeah, sortof. That is, Windows' and OSX' native browsers (IE and Safari)
each have their very own model of dealing with crypto hardware, which in
neither case involves PKCS#11 (I must admit that my colleague knows the
details there better than I do, though).

Firefox is the odd one out in that regard, where it doesn't use the
platform-specific crypto hardware APIs. That isn't a problem from our
POV (we support PKCS#11 for more than just firefox; and even if that
wasn't the case, having an option that uses a different mechanism is
useful as a debugging aid); but it does mean that with the current state
of affairs, Firefox is the only browser that doesn't support installing
our eID middleware without a step internal to the browser -- except for
Chrome on Linux, since it also uses libnss there.

> Windows has a *different* model for installing crypto hardware —
> really, your problem on Windows is that NSS doesn't use nss_capi by
> default, isn't it? (And that nss_capi hasn't been updated to CNG and
> that you should be shipping a minidriver or a CSP...)
>
> I think the same is true for OSX, with something like PKCS11_keychain?

Something along those lines, yes. As I said, I'm not too sure about the
details here, since my colleague usually deals with those.

--
Wouter Verhelst

[Wouter Verhelst]

On 08-05-15 15:46, David Woodhouse wrote:
> FWIW on Linux your installer/package needs to be shipping a module
> file like the one in /usr/share/p11-kit/modules/opensc.module

Well, since p11-kit is not found on the older distributions that we
still support, and non-functional on some newer distributions that we do
support, I'm not taking that step just yet; but yeah, I'll probably do
so at some point.

> (or
> isn't the eID card supported by OpenSC anyway, so do people need a
> third-party provider?)

There is some support in OpenSC, yes, but it lacks a few things that our
module does provide (e.g., we provide identity information through
CKO_DATA objects, which OpenSC doesn't do; also, there's two keys on the
card, but due to some peculiar strangeness in access rights of the
other, OpenSC only supports one of them).

--
Wouter Verhelst

[Ryan Sleevi]

On Fri, May 8, 2015 6:09 am, David Woodhouse wrote:
> On Linux distributions it *is* the platform's
> mechanism of choice for configuring PKCS#11 tokens. NSS needs to
> support it if it wants to integrate with the platform properly.

I'm sorry to continually push back on this, but you continue to make this
claim. This is a heady claim that lacks any evidence (so far) to support
it, beyond a particular distro.

1) You can't really talk about "the platform's mechanism" for Linux,
unless/until it's part of LSB. Beyond that, you're just waving your hands
in your air saying "for some distros". Linux is a world where a thousand
flowers bloom and a distro exists for every particular person's needs, so
you can't just make broad sweeping statements like this.

2) It is _an_ option for the platform. Indeed, I'd suggest you've got a
cart leading the horse. AFAICT, NSS *is* part of LSB (
http://www.linuxbase.org/betaspecs/lsb/LSB-Common/LSB-Common/requirements.html
) but p11-kit is not. So you can equally argue (and more accurately argue)
that p11-kit is failing to integrate with the platform properly by failing
to register itself with NSS.


I have no fundamental objections to p11-kit - indeed, I think it's quite
handy. But I do take issue with such broad sweeping claims used to argue
for supporting it. It's an option, I get that some distros really like I,
I *personally* like it for some cases, but that does *not* argue it's a
good thing.

[Ryan Sleevi]

On Fri, May 8, 2015 5:38 am, David Woodhouse wrote:
> These days it does. Modern systems ship with p11-kit², which exists

> precisely to fill that gap and provide "a standard discoverable
> configuration for installed PKCS#11 modules."

Your citation ( http://p11-glue.freedesktop.org/p11-kit.html ) fails to
support your claim that "modern systems ship it", as I've noted elsewhere.

> Although it happens to be Fedora which is first, we obviously expect
> other distributions and operating systems to follow suit — in
> practice, even if not with official packaging policy mandates.

And of course, this note - that it's Fedora only - directly counters the
claim above that "modern systems ship" (it's an implied subject that _all_
modern systems do so, which is incorrect. It's not even fair to say _some_
modern systems support it, since it seems, from your evidence, that _one_
modern system requires it)

> Does this seem like the right approach?

No, you should be able to do it w/o patching NSS.

> Under precisely what
> circumstances should we be doing it — should it be affected by the
> noModDB and noCertDB flags?

Yes, it should. You'll introduce your users to a host of security issues
if you ignore them (especially for situations like Chrome). For example,
if you did what you propose to do, you'd be exposing people's smart card
modules to arbitrary sandboxed Chrome processes - a step BACK for security
that would introduce huge attack surface (by transitive loading of all
those modules dependencies, including p11-kit's)

> We may wish to give some consideration to how that would work when it
> is being loaded into an NSS application which might have its own
> database in another directory (some broken applications like Firefox
> still don't use ~/.pki/nssdb ☹) or indeed in the *same* directory
> (like Chrome does).

And consideration to some applications (like Chrome) that would not want
to load it.

As I've said elsewhere, I'm not fundamentally opposed to p11-kit, but I do
hope you can take this considerations in approach and claims into
consideration before advocating support. I appreciate you're enthusiastic,
and I'm not trying to tell you no, but I am trying to help you understand
that you're not exactly going to win advocates with the current approach.

[David Woodhouse]

On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote:
> On Fri, May 8, 2015 5:38 am, David Woodhouse wrote:
> > These days it does. Modern systems ship with p11-kit², which exists
> > precisely to fill that gap and provide "a standard discoverable
> > configuration for installed PKCS#11 modules."
>
> Your citation ( http://p11-glue.freedesktop.org/p11-kit.html ) fails to
> support your claim that "modern systems ship it", as I've noted elsewhere.

Was it supposed to? I didn't think that observation actually needed to
be "supported".

I have some old Ubuntu and OpenSuSE virtual machines lying around; let's
see... yes, they both have it. Now, how do I try to remove it... on
Fedora, the dependencies are so fundamental that it looks like it's
trying to uninstall fairly much the *whole* system if I try to remove
p11-kit. SuSE is showing me this huge list of packages in a tiny 4-line
window in YAST, which doesn't like like it's the *whole* distribution
but it's a lot. For Ubuntu I'm not quite sure how to get the full
recursive list but it's going to take out a bunch of core GNOME stuff
and also anything linked against GnuTLS.

I don't think the "claim" that p11-kit is ubiquitous on Linux is really
a contentious one, is it?

It's also present in the ports systems for various BSD systems, and used
by the default build of other ports. And it's there for Solaris too.

> > Although it happens to be Fedora which is first, we obviously expect
> > other distributions and operating systems to follow suit — in
> > practice, even if not with official packaging policy mandates.
>
> And of course, this note - that it's Fedora only - directly counters the
> claim above that "modern systems ship"

No. It's only Fedora which (so far) has package guidelines explicitly
stating that its packages SHOULD consistently load the correct PKCS#11
providers according to the platform's configuration. But the others *do*
ship and use p11-kit, even if they're slower to actually try to achieve
*consistency* across the range of software they ship.

> > Does this seem like the right approach?
>
> No, you should be able to do it w/o patching NSS.

OK... how?

If the Shared System Database wasn't such an utter failure, not even
being used by Firefox itself, then just installing it there would have
been a nice idea. But *nothing* used the Shared System Database, and
there isn't even a coherent documented way for NSS users to discover
whether they should use it or not. If calling NSS_Initialize() with a
NULL configdir worked and did the right thing (sql:/etc/pki/nssdb where
it's setup, or sql:$HOME/.pki/nssdb otherwise), that would be nice...
but it doesn't.

I do have a horrid hack that works without patching NSS. Instead of a
symlink from /usr/lib64/libnssckbi.so to p11-kit-trust.so (which
replaces the NSS trust roots with something that's actually obeying the
system configuration), I instead symlink to p11-kit-proxy.so. That loads
not only the trust roots, but *also* the other PKCS#11 providers.

It works quite nicely in practice, but it isn't the *right* answer, and
there are corner cases where it doesn't do the right thing.

Got any other ideas?

> > Under precisely what
> > circumstances should we be doing it — should it be affected by the
> > noModDB and noCertDB flags?
>
> Yes, it should. You'll introduce your users to a host of security issues
> if you ignore them (especially for situations like Chrome). For example,
> if you did what you propose to do, you'd be exposing people's smart card
> modules to arbitrary sandboxed Chrome processes

So arbitrary sandboxes Chrome processes already have free rein to use
certificates in my NSS database? Isn't that a problem *already*? And if
people ever want to use the PKCS#11 token in their web browser, they're
going to need to expose it anyway. And if they don't, the p11-kit
configuration does permit a module to be visible in some applications
and not others.

> As I've said elsewhere, I'm not fundamentally opposed to p11-kit, but I do
> hope you can take this considerations in approach and claims into
> consideration before advocating support. I appreciate you're enthusiastic,
> and I'm not trying to tell you no, but I am trying to help you understand
> that you're not exactly going to win advocates with the current approach.

I'm happy to entertain any approach you care to suggest. The important
requirement is that software across the distribution should behave
*consistently*. If I have a certificate(+key) in my USB crypto token, I
should be able to *consistently* use that certificate in *any* piece of
software by using the *same* RFC7512 URI to identify it.

--
dwmw2

[David Woodhouse]

On Fri, 2015-05-08 at 15:00 -0700, Ryan Sleevi wrote:
> On Fri, May 8, 2015 6:09 am, David Woodhouse wrote:
> > On Linux distributions it *is* the platform's
> > mechanism of choice for configuring PKCS#11 tokens. NSS needs to
> > support it if it wants to integrate with the platform properly.
>
> I'm sorry to continually push back on this, but you continue to make this
> claim. This is a heady claim that lacks any evidence (so far) to support
> it, beyond a particular distro.

I believe it's *all* the major distros. Fairly much anything that ships
GNOME, anything that ships with a fully functional GnuTLS. But maybe I'm
nit-picking :)

> 1) You can't really talk about "the platform's mechanism" for Linux,
> unless/until it's part of LSB.

That's a good idea; we should look at including p11-kit in the LSB.

But yes, I said "Linux" and that's not what I meant. Linux really means
just the kernel, not the whole GNU/MIT/Xorg/etc/Linux operating system,
and not the LSB either.

Please forgive my laziness and pretend I actually said "all the major
desktop Linux distributions" instead of just "Linux".

Let's try again...

It would be nice if NSS would integrate with the system-wide
configuration for PKCS#11 providers that exists in all the major desktop
Linux distributions. One of them has recently added packaging guidelines
that its packages SHOULD do so, and for the others it's just a good
idea.

There, is that better?

> So you can equally argue (and more accurately argue)
> that p11-kit is failing to integrate with the platform properly by failing
> to register itself with NSS.

I'm happy with looking at it like that. Perfectly happy.

So tell me: how does a PKCS#11 provider module "register itself with
NSS" such that it's automatically loaded in NSS applications? I know how
to do it for GnuTLS and I know how to do it for OpenSSL(+engine_pkcs11).
Tell me how to do it for NSS and my work here is done.

In fact, if you look at the straw-man patch I sent, that was basically
all I *was* doing. It would be a configure/build-time option to load a
specific module automatically. On systems that *want* it, that they'd
configure it to load p11-kit-proxy.so. On others, they wouldn't.

--
dwmw2

[Ryan Sleevi]

On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote:
> On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote:
> > Yes, it should. You'll introduce your users to a host of security issues
> > if you ignore them (especially for situations like Chrome). For example,
> > if you did what you propose to do, you'd be exposing people's smart card
> > modules to arbitrary sandboxed Chrome processes
>
> So arbitrary sandboxes Chrome processes already have free rein to use
> certificates in my NSS database? Isn't that a problem *already*? And if
> people ever want to use the PKCS#11 token in their web browser, they're
> going to need to expose it anyway. And if they don't, the p11-kit
> configuration does permit a module to be visible in some applications
> and not others.

No David, that's quite the opposite of what I was saying. If you did what
you propose - patching to ignore the noModDB & friends - you'd be
introducing security issues. The security issues do not exist now. Your
patch would introduce them.

You don't need to expose it to the sandbox to use PKCS#11 in the web
browser. That's not how modern sandboxed browsers work.

And yes, your conclusion further emphasizes my original point - some
applications explicitly do not wish to have p11-kit introduced, and by
just blithely introducing it, you're introducing security vulnerabilities.

[Ryan Sleevi]

On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote:

> > No, you should be able to do it w/o patching NSS.
>
> OK... how?
>
> If the Shared System Database wasn't such an utter failure, not even
> being used by Firefox itself, then just installing it there would have
> been a nice idea. But *nothing* used the Shared System Database, and
> there isn't even a coherent documented way for NSS users to discover
> whether they should use it or not. If calling NSS_Initialize() with a
> NULL configdir worked and did the right thing (sql:/etc/pki/nssdb where
> it's setup, or sql:$HOME/.pki/nssdb otherwise), that would be nice...
> but it doesn't.

This is demonstrably not true, such in the case of Chrome.

Or did you mean Fedora's particular interpretation of how things should look?

Just use the canonical way to configure NSS to look for tokens - in which
it also finds your meta-configuration token - namely sql:$HOME/.pki/nssdb

And lean on the applications that don't respect NSS's configuration
semantics rather than trying to redefine NSS's configuration semantics.

[David Woodhouse]

On Sun, 2015-05-10 at 12:07 -0700, Ryan Sleevi wrote:
> On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote:

> > On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote:
> > > Yes, it should. You'll introduce your users to a host of security issues
> > > if you ignore them (especially for situations like Chrome). For example,
> > > if you did what you propose to do, you'd be exposing people's smart card
> > > modules to arbitrary sandboxed Chrome processes
> >
> > So arbitrary sandboxes Chrome processes already have free rein to use
> > certificates in my NSS database? Isn't that a problem *already*? And if
> > people ever want to use the PKCS#11 token in their web browser, they're
> > going to need to expose it anyway. And if they don't, the p11-kit
> > configuration does permit a module to be visible in some applications
> > and not others.
>
> No David, that's quite the opposite of what I was saying. If you did what
> you propose - patching to ignore the noModDB & friends - you'd be
> introducing security issues. The security issues do not exist now. Your
> patch would introduce them.

I don't believe I've proposed any such patch. I've posted a straw man
patch, basically saying "We probably want to load the PKCS#11 modules
specified by the system around here, but we need to take noModDB and
friends into account and I'm not quite sure of the semantics so can
someone help.

> You don't need to expose it to the sandbox to use PKCS#11 in the web
> browser. That's not how modern sandboxed browsers work.

That sounds like a bit of a failure of the sandboxing to me. Just so I
understand what you're saying... regardless of whether the browser
complies with the system policy for PKCS#11 modules, it's considered
acceptable that a sandbox can happily authenticate using any of the
certificates in my NSS database and any of the PKCS#11 tokens that I
have manually enabled?

> And yes, your conclusion further emphasizes my original point - some
> applications explicitly do not wish to have p11-kit introduced, and by
> just blithely introducing it, you're introducing security vulnerabilities.

Let's be clear here. Remember, p11-kit already makes the configuration
of PKCS#11 providers a per-application choice. So, if I understand
correctly, what we're talking about here is a case where:

1. The PKCS#11 provider module has been installed in the system with a
configuration indicating that it *should* be loaded into the browser.

2. The user has entered the PIN to unlock the token (or the token
doesn't *have* a PIN and can be accessed without it!).

3. The browser permits a sandbox to authenticate using keys in that
token, just like it permits the same sandbox to use keys in the
*default* NSS database and any manually-configured PKCS#11 tokens.

And your assertion here appears to me that the *problem* in this
situation would be the implicit step 1½ that I didn't mention
originally, which is the part where we *honour* the configuration
mentioned in step 1.

It does seem to be rather an odd objection, to me.

--
dwmw2

[Ryan Sleevi]

On Sun, May 10, 2015 12:31 pm, David Woodhouse wrote:
> > You don't need to expose it to the sandbox to use PKCS#11 in the web
> > browser. That's not how modern sandboxed browsers work.
>
> That sounds like a bit of a failure of the sandboxing to me. Just so I
> understand what you're saying... regardless of whether the browser
> complies with the system policy for PKCS#11 modules, it's considered
> acceptable that a sandbox can happily authenticate using any of the
> certificates in my NSS database and any of the PKCS#11 tokens that I
> have manually enabled?

No, you don't understand what I'm saying, and have reached a conclusion
that again is the opposite.

I will try to break it down to it's core parts:

- Don't load a module unless the user has explicitly asked or configured
that module to be loaded.
- Do not patch NSS to load modules outside of the explicitly requested
modules.

Your patch fails on both of those.

It's really that simple. If you don't try to patch NSS to do something
crazy, it will surprisingly not do something crazy.

And to be as abundantly explicit as I can be: No, your assumptions about
how sandboxing works are quite flawed. The fact is that the module is
*not* loaded in the sandbox is the thing to preserve, which your patch
destroy.

If the user requests NSS to load a module. It should load that module. And
that module only. Period.

[David Woodhouse]

On Sun, 2015-05-10 at 12:11 -0700, Ryan Sleevi wrote:
> On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote:

> > > No, you should be able to do it w/o patching NSS.
> >
> > OK... how?
> >
> > If the Shared System Database wasn't such an utter failure, not even
> > being used by Firefox itself, then just installing it there would have
> > been a nice idea. But *nothing* used the Shared System Database, and
> > there isn't even a coherent documented way for NSS users to discover
> > whether they should use it or not. If calling NSS_Initialize() with a
> > NULL configdir worked and did the right thing (sql:/etc/pki/nssdb where
> > it's setup, or sql:$HOME/.pki/nssdb otherwise), that would be nice...
> > but it doesn't.
>
> This is demonstrably not true, such in the case of Chrome.

Which part are you talking about? That NSS_Initialize() with a NULL
configdir can quietly Do The Right Thing? If that now works, it's
changed since I last looked.

Or that Chrome can use sql:/etc/pki/nssdb and libnsssysinit.so, and fall
back to sql:$HOME/.pki/nssdb when libnsssysinit.so isn't set up? Again,
that would be a change since I last looked at it.

Or that there is coherent documentation? The best I've found is the page
at https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX — but that starts by
saying that applications should use
NSS_InitReadWrite(“sql:/etc/pki/nssdb”) which AIUI is just broken on any
system where /etc/pki/nssdb/pkcs11.txt doesn't cause libnsssysinit.so to
get loaded.

> Or did you mean Fedora's particular interpretation of how things should look?

I'm not aware of any "Fedora-specific interpretation of how things
should look". Can you elucidate?

Fedora does have this odd script which turns libnsssysinit.so on and off
in sql:/etc/pki/nssdb, for which I don't quite understand the
motivation. But that just switches the system between two configurations
that an application presumably has to be able to cope with anyway.

> Just use the canonical way to configure NSS to look for tokens - in which
> it also finds your meta-configuration token - namely sql:$HOME/.pki/nssdb

That's not system-wide; it's per-user. And in practice, I think Chrome
and Evolution are the only common apps that even use *that*.

> And lean on the applications that don't respect NSS's configuration
> semantics rather than trying to redefine NSS's configuration semantics.

Like Firefox? Bugs have been filed there for years...

--
dwmw2

[David Woodhouse]

On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote:
> If the user requests NSS to load a module. It should load that module.
> And that module only. Period.

The canonical per-user way to request an application to load a module is
for me to create a file in ~/.config/pkcs11/modules/*.module which looks
something like:

module: /home/dwmw2/my-provider.so
enable-in: firefox curl evolution openconnect openvpn

I tried that. It didn't work with Firefox or Evolution, which use NSS.
It worked with the others, which are using GnuTLS and OpenSSL.

Yes, you can tell me "NSS is special and different and doesn't actually
honour the platform's configuration like other things do".

That was precisely the status quo that I was trying to fix.

--
dwmw2

[Ryan Sleevi]

On Sun, May 10, 2015 12:57 pm, David Woodhouse wrote:
> On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote:
> > If the user requests NSS to load a module. It should load that module.
> > And that module only. Period.
>
> The canonical per-user way to request an application to load a module is

NSS_Initialize and SECMOD_LoadModule.

Respect the API. Don't violate the API.

[David Woodhouse]

Sure, we can modify all the applications to do this and load
p11-kit-proxy.so by default. Then the example configuration I showed
would actually *work*. That was the third of the potential approaches I
referenced from my email at the beginning of this thread, if you recall.

But if we're going to do a bombing run across NSS-using applications and
patch them all, I suspect we might do better to convert them to using
the Shared System Database. Then a distribution which wants to use
p11-kit-proxy can just stick that in sql:/etc/pki/nssdb and we're done —
and NSS doesn't have to know anything about p11-kit specifically.

This was the first suggestion in my list. But my experience of trying to
get the Shared System Database to work has not been entirely happy :)

Certainly, having to touch *all* the apps wasn't my first choice, but if
that's the consensus — if NSS *really* doesn't want to support an
optional way to load an additional 'system' PKCS#11 provider by default
under the right circumstances — then we can certainly attempt it.

--
dwmw2

[Ryan Sleevi]

On Mon, May 11, 2015 4:09 am, David Woodhouse wrote:
> I completely agree that Chrome should only ever load the modules which
> are configured to be loaded into Chrome. I'm surprised you feel the
> need to mention that.

Because you still don't understand, despite how many ways I'm trying to
say it.

It's not simply sufficient to load module X into Chrome or not. p11-kit's
security model is *broken* for applications like Chrome, at least with
respect to how you propose to implement.

Let's say you've got Module X.

Today, Chrome controls loading of modules. It can load module X into the
browser process (and trusted process) and *NOT* load Module X into a
sandboxed zygote process that it then uses to start renderers and such.

Because Chrome fully controls module loading, and uses the NSS documented
APIs, it can ensure that things are appropriately controlled. It can
guarantee exactly which modules can be loaded into the untrusted process -
such as the read-only, non-modiable root trust module.

You still don't seem to understand that distinction, because you keep
calling it "broken". No, it's only broken with something like p11-kit
comes along and violates the API guarantees.

That's why I keep reiterating that the reasons for NSS's per-application
config extend beyond just "No one's gotten around to it" and are deeply
intertwined with *legitimate application's needs that p11-kit so far fails
to respect.

I don't know how many ways I can say it, but I'm trying to provide a
simple example that can be empirically validated about how your proposal
*fails* and causes security issues.

I think you keep leaping ahead of yourself in proposing, so I would again,
as I have privately, encouraged you to go back, start from first
principals, and make sure you *understand the requirements* before jumping
too far into proposing solutions. I think a solution can be found, but I
think we're going to continue to waste time if every other email jumps
three steps ahead.

[Brian Smith]

David Woodhouse <dw...@infradead.org> wrote:

> The sysadmin should be able to configure things for *all* users
> according to the desired policy, rather than forcing each user to set
> things up for themselves.
>
> And in turn the *developers* of the operating system distribution
> should be able to set a default policy for the sysadmin to build upon.
>

Actually, this is the opposite of Firefox's policy. Firefox *intentionally*
doesn't do that. It may be possible to hack things to make it work (I
believe RHEL and Fedora do something like that already, for example), but
those hacks violate the spirit, if not the letter, of the Firefox trademark
policy regarding unauthorized modifications of Firefox. And, also, AFAICT,
those kinds of hacks may stop working at any time.

Said differently, there is nothing special about Linux. Just as Firefox
intentionally doesn't use Windows's central certificate trust database on
Windows, and just as it doesn't use Mac OS X's central certificate trust
database on Mac OS X, it shouldn't use a Linux distro's central certificate
trust database.

Put yet another way, it is basically Mozilla's policy to make sysadmins'
and Linux distros' jobs difficult in this area, because doing so is sort of
required for Mozilla to maintain autonomy over its root CA inclusion
policy. Thus, "fixing" this kind of problem is actually harmful.

That said, of course it would be nice if smart cards and client
certificates worked automatically, but those improvements need to be in
such a way that they wouldn't change the trust and non-trust of server
certificates.

Cheers,
Brian

[Peter Bowen]

On Tue, May 12, 2015 at 8:40 AM, David Woodhouse <dw...@infradead.org> wrote:

> On Mon, 2015-05-11 at 11:21 -0700, Ryan Sleevi wrote:
>> It's not simply sufficient to load module X into Chrome or not. p11-kit's
>> security model is *broken* for applications like Chrome, at least with
>> respect to how you propose to implement.
>

> I've proposed at least four different options and asked for opinions
> on which might be better and how to refine them; let's not get too
> hung up on "how I propose to implement".

How about an even simpler solution? Don't have p11-kit load the
PKCS#11 modules, just provide a list of paths and let the application
pass those to NSS. That way the application can choose to
transparently load modules without user interaction, offer a UI option
for "load system modules", or provide a pick list of module to load.

[Ryan Sleevi]

On Tue, May 12, 2015 9:44 am, Peter Bowen wrote:
> How about an even simpler solution? Don't have p11-kit load the
> PKCS#11 modules, just provide a list of paths and let the application
> pass those to NSS. That way the application can choose to
> transparently load modules without user interaction, offer a UI option
> for "load system modules", or provide a pick list of module to load.

Right, that's known as an NSS Module DB (and is in fact what the
pkcs11.txt parser is)

The shared library reports back the supported modules and configuration
flags, and then NSS loads and initializes them as if they were first-class
modules.

http://mxr.mozilla.org/nss/source/lib/sysinit/nsssysinit.c is an example
of this.

[Yes, it relies on a non-standard extension to PKCS#11's C_Initialize;
caveat emptor]

[Wouter Verhelst]

On 11-05-15 20:21, Ryan Sleevi wrote:
> On Mon, May 11, 2015 4:09 am, David Woodhouse wrote:
>> I completely agree that Chrome should only ever load the modules which
>> are configured to be loaded into Chrome. I'm surprised you feel the
>> need to mention that.
>
> Because you still don't understand, despite how many ways I'm trying to
> say it.
>

> It's not simply sufficient to load module X into Chrome or not. p11-kit's
> security model is *broken* for applications like Chrome, at least with
> respect to how you propose to implement.
>

> Let's say you've got Module X.
>
> Today, Chrome controls loading of modules. It can load module X into the
> browser process (and trusted process) and *NOT* load Module X into a
> sandboxed zygote process that it then uses to start renderers and such.

Actually, no, Chrome doesn't control anything. Enabling a PKCS#11 module
in chrome requires one to muck about with modutil, which is rather ugly.

--
Wouter Verhelst