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
