GNOME Bugzilla – Bug 741293
Smartcard plugin does not find system-configured PKCS#11 modules
Last modified: 2019-03-20 11:20:32 UTC
Modern systems use p11-kit for configuring the PKCS#11 modules which are available. For example the OpenSC package is likely to drop a file somewhere like /usr/share/p11-kit/modules/ which automatically registers the opensc-pkcs11.so module and makes it available to well-behaving applications. The group "well-behaving applications" does not appear to include g-s-d. If you're going to use a library like NSS which is known not to get this right, you probably need to do something like manually loading the p11-kit-proxy.so module with SECMOD_LoadUserModule(). Better still, just ditch NSS and use p11-kit libraries directly if they offer the functionality you need.
if you run: pk11install -p /etc/pki/nssdb 'name="PKCS #11 Proxy Module" library=p11-kit-proxy.so' do things start working?
If I do that, pam_pkcs11 breaks. It also opens /etc/pki/nssdb but then wants to open the OpenSC module *manually* outside p11-kit. And can't if p11-kit-proxy has already opened it. Which is arguably a pam_pkcs11 bug, I suppose, but if you're going to suggest screwing with the NSS database that *everyone* shares then you get to care :) (Not that *everyone* does share /etc/pki/nssdb. There's also sql:/etc/pki/nssdb which is the new SQL format, which is more sensible for people to be using. And most major NSS applications don't use it at all, of course.)
(yes, it does fix the g-s-d smartcard though)
can you post your pam_pkcs11.conf ? it sounds like you have configured it to use a specific module, instead picking up the default module from nss. I think you want to set the pkcs11 module to the magic string, "any module", in your configuration.
Created attachment 292483 [details] pam_pkcs11.conf This isn't very much edited from the default pam_pkcs11.conf. I'm not really using it in anger; just testing with 'pkcs11_inspect debug'. I've changed the setting of 'use_pkcs11_module' from 'coolkey' to 'opensc' (and observed that 'any module' doesn't work there). And set the nss_dir under the opensc module configuration to /etc/pki/nssdb since the default nss_dir of /etc/pam_pkcs11/nssdb doesn't exist. (I've also tried making it use p11-kit-proxy.so but without much luck so far; either it or I am confused about which slot to use).
(If the slot to use were provided in the standard PKCS#11 URI form instead of a fairly opaque number, that would make life much easier. But this *wasn't* a pam_pkcs11 bug...)
so try changing use_pkcs11_module to "automatic" and then adding this: pkcs11_module automatic { module = "any module" description = "Automatic" slot_num = 0; nss_dir = /etc/pki/nssdb; cert_policy=ca, signature; }
as to which slot to use... what's the output of modutil -list -dbdir /etc/pki/nssdb/ ?
(In reply to comment #8) > as to which slot to use... what's the output of > modutil -list -dbdir /etc/pki/nssdb/ Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. p11-kit-proxy.so library name: /usr/lib64/p11-kit-proxy.so slots: 9 slots attached status: loaded slot: /etc/pki/ca-trust/source token: System Trust slot: /usr/share/pki/ca-trust-source token: Default Trust slot: SSH Keys token: SSH Keys slot: Secret Store token: Secret Store slot: Gnome2 Key Storage token: Gnome2 Key Storage slot: User Key Storage token: User Key Storage slot: Virtual hotplug slot token: slot: Yubico Yubikey NEO CCID 00 00 token: PIV_II (PIV Card Holder pin) slot: Feitian SCR301 01 00 token: Red Key (User PIN) -----------------------------------------------------------
(In reply to comment #7) > so try changing use_pkcs11_module to "automatic" > and then adding this: > > pkcs11_module automatic { > module = "any module" > description = "Automatic" > slot_num = 0; > nss_dir = /etc/pki/nssdb; > cert_policy=ca, signature; > } That works; thanks!. Should this be the default configuration for pam_pkcs11 then? Along with installing p11-kit-proxy.so into /etc/pki/nssdb *and* sql:/etc/pki/nssdb? Perhaps in a mode which *doesn't* install the System Trust and Default Trust tokens, since those are provided by libnssckbi.so only for applications which *choose* to load that. (In the Fedora case libnssckbi.so is a symlink to p11-kit-trust.so). I have two hardware tokens installed; I can't seem to make it use any but the last in the list from comment #9. I can unplug and reinsert devices until a different token is last, and then pkcs11_inspect will use that one, but I can't seem to make the slot_num= setting do anything. What it really ought to be taking is a URI like pkcs11:model=PKCS%2315;manufacturer=EnterSafe;serial=3010053715050710;token=Red%20Key%20%28User%20PIN%29
> That works; thanks!. Should this be the default configuration for pam_pkcs11 > then? probably, in Fedora, at least. > I have two hardware tokens installed; I can't seem to make it use any but the > last in the list from comment #9. I can unplug and reinsert devices until a > different token is last, and then pkcs11_inspect will use that one, but I can't > seem to make the slot_num= setting do anything. What it really ought to be > taking is a URI like > pkcs11:model=PKCS%2315;manufacturer=EnterSafe;serial=3010053715050710;token=Red%20Key%20%28User%20PIN%29 Try dropping slot_num=0 and adding slot_description="Feitian SCR301 01 00"
(In reply to comment #11) > Try dropping slot_num=0 and adding slot_description="Feitian SCR301 01 00" None of these four strings appear to work. It says 'no token available'. slot: Feitian SCR301 00 00 token: Red Key (User PIN) slot: Yubico Yubikey NEO CCID 01 00 token: PIV_II (PIV Card Holder pin)
(In reply to comment #12) > (In reply to comment #11) > > Try dropping slot_num=0 and adding slot_description="Feitian SCR301 01 00" > > None of these four strings appear to work. It says 'no token available'. Oh, that's because there's a special case for the "any module" setup. Having a slot_num other than zero doesn't work (it doesn't even look at slot_num and just returns the first usable one anyway). And matching on slot_description is just unimplemented. Does this look like the right fix? It seems to work: https://github.com/dwmw2/pam_pkcs11/commit/32920ae5eded
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Try dropping slot_num=0 and adding slot_description="Feitian SCR301 01 00" > > > > None of these four strings appear to work. It says 'no token available'. > > Oh, that's because there's a special case for the "any module" setup. Having a > slot_num other than zero doesn't work (it doesn't even look at slot_num and > just returns the first usable one anyway). ah okay. > And matching on slot_description is > just unimplemented. Does this look like the right fix? It seems to work: > https://github.com/dwmw2/pam_pkcs11/commit/32920ae5eded Well this is more Bob Relyea's area of expertise, not mine, but I don't think it's quite right. What if the slot you're matching doesn't have a token in it? Also, I think you leak a reference to the slot if the name doesn't match. Probably the right answer is to use PK11_FindSlotByName()
Thanks for looking at it. I filed https://bugzilla.redhat.com/show_bug.cgi?id=1173585 Back to the gnome-settings-daemon issue... I'm not sure why it would be 'NOTGNOME'. This could be fixed by avoiding NSS and using p11-kit directly, or perhaps by explicitly loading p11-kit-proxy.so with SECMOD_LoadUserModule(). NSS is *known* not to do the right thing here. I'm not sure it makes sense to choose to use it anyway and then say "oh, it's someone else's fault" :) Would you be interested in patches to stop using NSS and use p11-kit instead, to make it do the right thing?
The smartcard stack was originally designed with 1) coolkey 2) system nssdb and 3) pam_pkcs11 in mind. In fact, IIRC, we added /etc/pki/nssdb in ~2007 or something specifically so we'd have a central place to register pkcs11 modules (and certs) It looks like you got things working with configuration changes, and a pam_pkcs11 patch, so I closed NOTGNOME, shrugging your issue off as a pam_pkcs11 one. I'm not opposed to switching away from nssdb for smartcard registration to p11-kit. I think it's a really good idea actually, but if you could get coolkey and pam_pkcs11 on board at the same time that would be good. What I don't want is an impedance mismatch between pam_pkcs11 and gnome-settings-daemon. If we all standarize on one place, great. I'm also curious what Bob Relyea's take is.
You are *absolutely* right that we don't want an impedance mismatch between pam_pkcs11 and gnome-settings-daemon. But I'd go further than that and insist that we don't want any impedance mismatch at all across the whole system — which seems to be what you were also suggesting would be 'great'. That's *why* I'm objecting to the current state of things. My smartcard is working in well-behaved applications; OpenSC registered itself with p11-kit and it should Just Work. Anything *not* seeing my smartcard is not a well-behaved application. Hence the tracker bug and a bunch of subordinate bugs I've just filed in Fedora (one of which is against pam_pkcs11 and is probably a better place to continue this conversation): https://bugzilla.redhat.com/showdependencytree.cgi?id=1173546 As for pam_pkcs11 and g-s-d, there's *already* a mismatch. Because pam_pkcs11 *isn't* using the 'any module' setup and /etc/pki/nssdb by default. The default config file we ship in Fedora is explicitly loading libcoolkey by default. These days, the /etc/pki/nssdb thing has mostly failed to be adopted even by the "in-house" NSS applications like Thunderbird and Firefox, and p11-kit has taken over as the "one place" to register PKCS#11 modules. It's time to make sure that both pam_pkcs11 and g-s-d (as well as the rest of the system) are doing the right thing. If that can work with NSS, great. Perhaps it can be done by explicitly loading p11-kit-proxy.so as the PKCS#11 provider, as long as that doesn't cause issues when NSS *eventually* does manage to start loading the p11-kit modules properly for itself. Otherwise, maybe we can build pam_pkcs11 with OpenSSL again; I've made sure that works. And I can provide patches to g-s-d to match that behaviour. It really depends on how soon we can make NSS actually behave correctly.
Hi, (In reply to comment #17) > As for pam_pkcs11 and g-s-d, there's *already* a mismatch. Because pam_pkcs11 > *isn't* using the 'any module' setup and /etc/pki/nssdb by default. The default > config file we ship in Fedora is explicitly loading libcoolkey by default. You're right, but in practice it didn't matter for the originally supported configuration (coolkey), so I guess no one noticed ? > These days, the /etc/pki/nssdb thing has mostly failed to be adopted even by > the "in-house" NSS applications like Thunderbird and Firefox, and p11-kit has > taken over as the "one place" to register PKCS#11 modules. It's time to make > sure that both pam_pkcs11 and g-s-d (as well as the rest of the system) are > doing the right thing. sounds good. and coolkey and pk11install
(In reply to comment #18) > You're right, but in practice it didn't matter for the originally supported > configuration (coolkey), so I guess no one noticed ? Makes sense. > > These days, the /etc/pki/nssdb thing has mostly failed to be adopted even by > > the "in-house" NSS applications like Thunderbird and Firefox, and p11-kit has > > taken over as the "one place" to register PKCS#11 modules. It's time to make > > sure that both pam_pkcs11 and g-s-d (as well as the rest of the system) are > > doing the right thing. > sounds good. and coolkey and pk11install Yeah. For coolkey there's https://bugzilla.redhat.com/show_bug.cgi?id=1073320 and the point is that once that's fixed (and applications are doing the Right Thing), pk11install shouldn't be necessary at all.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/260.