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 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: 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 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 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: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, 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
