Re: PKCS#11 platform integration
On Tue, 2015-05-12 at 10:17 -0700, Ryan Sleevi wrote:
> 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]
I think it's actually an extra entry point 'NSS_ReturnModuleSpecData'
in the module, isn't it? Or am I thinking of something different?
Either way, I think we could certainly implement a module which does
this instead of doing what p11-kit-proxy.so does. Such a module
doesn't need to provide a C_GetFunctionList at all; it would *just*
provide a Module DB.
However, that doesn't really address the problem of *how* we get NSS
to load the module in question by default. We still have a chicken-and
-egg problem with loading it.
(There's also a tangential discussion to be had here about whether
it's best to load modules in NSS as 'first-class modules', or
whether to do it through p11-kit{,-proxy}. The issue is as
follows:
Some applications end up loading more than one crypto library at a
time — they use different plugins or higher-level protocol
libraries, each of which might have been built against a different
underlying crypto library. And once we start to see all crypto
libraries consistently loading the same set of PKCS#11 tokens
according to the policy, we need to care about what happens when
a given PKCS#11 module is loaded more than once into the process.
See http://p11-glue.freedesktop.org/doc/p11-kit/sharing.html
In the short term, I suspect that loading p11-kit-proxy might be
the better option. However, in the longer term perhaps we want
to be loading modules into NSS in a manner which is compatible
with the p11-kit 'sharing' mechanism. And then it would indeed
be nicer to load the p11-kit configured modules as 'first-class'
modules.)
And just to follow up another slight tangent on the separate
requirement to identify objects by a RFC7512 PKCS#11 URI... Ryan, in
bug 1162897 you said you don't want NSS to parse those for itself, and
that it should use a separate library. That functionality is also
provided by p11-kit.
So *maybe* the best option when all is considered is just to bite the
bullet and start using p11-kit directly from NSS. Which raises more
questions... do you make it optional? The RFC7512 parsing would then
be absent from NSS when built without p11-kit, so what form of failure
mode and fallback would you have? And how ugly would it be to
*conditionally* use the p11-kit wrappers for managing multiple PKCS#11
consumers?
But back to the point about how we get NSS to load the appropriate
module(s) by default...
Ideally, I think this should Just Work. I don't think we want to have
to do a bombing run on all NSS-using applications and modify them
individually. But if we *were* going to do that kind of thing, then I
think we might as well just fix them all to use the Shared System
Database. rather than anything new. Does that seem like a reasonable
assertion? Then the distributions can just add p11-kit-proxy.so to
their /etc/pki/nssdb/pkcs11.txt and we're done.
If we *did* want to make apps consistently use the Shared System DB,
we'd want a simple way for applications to *know* whether they should
use sql:/etc/pki/nssdb or $HOME/.pki/nssdb. Currently there is no
coherent answer to that, that I'm aware of. I *really* don't want to
end up adding the the open-coded version from
https://bugzilla.mozilla.org/show_bug.cgi?id=490238#c37 to a whole
bunch of individual applications!
If we want to do it *without* having to modify all applications — and
I think we do — then perhaps the best place for it is the softokn's
Module DB implementation. So either in NSC_ModuleDBFunc() or the
NSSUTIL_DoModuleDBFunction() that it calls through to. The softokn
would just transparently add the appropriate module(s) to the list it
obtains from the DB.
In the short term, it would be quite nice to have a *plan* even if
it's going to take a while to come to fruition. In particular, it
would be nice to know what interim measures we can take — for example
can we add p11-kit-proxy.so to /etc/pki/nssdb/pkcs11.txt or would that
actually end up conflicting with whatever the real solution ends up
looking like? Or should we patch hi
Re: PKCS#11 platform integration
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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] -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
On Tue, May 12, 2015 at 8:40 AM, David Woodhouse 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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". I even have a fifth, which is impractical but perhaps serves to highlight the intent better: Option 5: Hack the *kernel* so that whenever any userspace application opens a file named "pkcs11.txt' it magically sees extra contents in that file. The extra contents being appropriate text to cause NSS to load the additional PKCS#11 modules that are present in the p11-kit policy for the application in question. Obviously it would be insane to actually implement it that way, but perhaps it makes the intent clearer. Certainly I think it should help to alleviate the concern below, which seems to be a misunderstanding... > Let's say you've got Module X. ... where 'got' means it's listed in ~/.pki/nssdb/pkcs11.txt, yes? > 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. The documented API in the case of the sandbox being NSS_NoDB_Init(), yes? ¹ Were you worried that the p11-kit configured modules would get loaded in that case? They certainly shouldn't, and I thought I'd made a fairly explicit reference to that in my first message in this thread. The idea is that p11-kit listed modules should be treated *just* like the modules in the pkcs11.txt file. If you aren't loading the latter (as in the sandbox case), you shouldn't get the former. In fact, another way of implementing the integration might possibly be just to patch NSC_ModuleDBFunc() in the softokn and make it transparently add the list of modules specified by p11-kit to what it finds in pkcs11.txt? (Or perhaps just add p11-kit-proxy.so). -- dwmw2 ¹ https://git.chromium.org/gitweb/?p=chromium/src/crypto.git;a=blob;f=nss_util.cc;h=062bcb51;hb=HEAD#l686 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
On Mon, 2015-05-11 at 11:24 -1000, Brian Smith wrote: > > 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. I think we can treat the question of *trusted* certificates as an orthogonal issue. If you look at the (incomplete) list of options I posted¹ for how we might make NSS honour the p11-kit-configured list of tokens, I explicitly mentioned the fact that we *don't* want to automatically load the trust roots; only the additional user tokens. NSS applications should get their trust roots, if they want them, from libnssckbi.so. If someone symlinks libnssckbi.so to something else rather than the one that NSS provides... well, that's a different conversation :) -- dwmw2 ¹ http://lists.freedesktop.org/archives/p11-glue/2014-December/000528.html smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
David Woodhouse 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote: > > - 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. Quite right; that's absolutely how we should behave. As long as we include the sysadmin as a 'user' in the above definition, of course. 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. I mention that because it cuts to the heart of what we're actually trying to achieve here — being able to set a *platform* policy which is then honoured consistently by all applications regardless of which crypto library they're using today. Note that in the case of p11-kit, the policy you set is already a per -application choice. You can set a module to be loaded in one application, but not in another. Which is something that AFAIK you *cannot* do with a shared NSS database in $HOME/.pki/nssdb. 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. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
On Sun, 2015-05-10 at 13:50 -0700, Ryan Sleevi wrote: > 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. 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [bulk] PKCS#11 platform integration
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 platform integration
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [bulk] PKCS#11 platform integration
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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [bulk] PKCS#11 platform integration
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [bulk] PKCS#11 platform integration
On Fri, 2015-05-08 at 15:23 +0200, Wouter Verhelst wrote: > 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". Right. On platforms where p11-kit doesn't *already* exist, using it doesn't help you. It only *adds* work for the end-user. I suspect the best answer for Windows and OSX is to make NSS integrate properly by automatically loading nss_capi and its OSX equivalent, if/when those modules are production-ready. Perhaps it's something to bear in mind when adding the code to load p11-kit-proxy.so; that on other platform it might be some *other* module that gets loaded. FWIW on Linux your installer/package needs to be shipping a module file like the one in /usr/share/p11-kit/modules/opensc.module (or isn't the eID card supported by OpenSC anyway, so do people need a third-party provider?) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [bulk] PKCS#11 platform integration
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [bulk] PKCS#11 platform integration
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. But then again, isn't PKCS#11 itself an impostor on those platforms anyway? 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? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [bulk] PKCS#11 platform integration
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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
PKCS#11 platform integration
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."
In the interest of consistency, the Fedora Linux distribution now has
packaging guidelines³ which say that any software which uses X.509
certificates SHOULD support PKCS#11, SHOULD load the correct PKCS#11
providers according to the system configuration, and SHOULD allow
objects to be specified using a PKCS#11 URI according to RFC7512.
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.
I'd very much like those guidelines *not* to implicitly translate to
"build your package against a crypto library other than NSS". I've
already found cases where the bugs⁴ I'm filing can by fixed just by
building the package against GnuTLS instead, but I'm reluctant to push
for that.
I've already started a separate thread about supporting RFC7512 URIs
as object specifiers; this one is about loading the right modules...
There are a number of potential approaches to this, some discussed at
http://lists.freedesktop.org/archives/p11-glue/2014-December/000528.html
Probably the best option is to make nss_InitModules() automatically
load p11-kit-proxy.so as an additional provider. Here's a straw man
patch which attempts that:
--- nss/lib/nss/nssinit.c~ 2014-10-10 17:56:55.0 +0100
+++ nss/lib/nss/nssinit.c 2014-12-11 16:26:58.113699892 +
@@ -435,7 +435,13 @@ loser:
SECMODModule *module = SECMOD_LoadModule(moduleSpec,NULL,PR_TRUE);
PR_smprintf_free(moduleSpec);
if (module) {
- if (module->loaded) rv=SECSuccess;
+ if (module->loaded) {
+ SECMODModule *mod2 =
SECMOD_LoadModule("library=/usr/lib64/p11-kit-proxy.so",module,PR_FALSE);
+ if (mod2) {
+ SECMOD_DestroyModule(mod2);
+ }
+ rv=SECSuccess;
+ }
SECMOD_DestroyModule(module);
}
}
Does this seem like the right approach? Under precisely what
circumstances should we be doing it — should it be affected by the
noModDB and noCertDB flags?
It's also possible for users to add a module to their p11-kit
configuration which exposes the per-user NSS DB from ~/.pki/nssdb so
that it's consistently visible in all applications.
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).
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
¹ https://bugzilla.mozilla.org/show_bug.cgi?id=248722
² http://p11-glue.freedesktop.org/p11-kit.html
³ https://fedoraproject.org/wiki/PackagingDrafts/SSLCertificateHandling
⁴ https://bugzilla.redhat.com/showdependencytree.cgi?id=PKCS11
smime.p7s
Description: S/MIME cryptographic signature
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
