On Mon, 2014-12-08 at 13:05 +0000, David Woodhouse wrote: > On Mon, 2014-12-08 at 10:15 +0000, Martinsson Patrik wrote: > > So, to summarize, > > $> sudo update-alternatives --install /usr/lib64/libnssckbi.so > > libnssckbi.so.x86_64 /usr/lib64/p11-kit-proxy.so 1000 > > > > $> cat /etc/pki/nssdb/pkcs11.txt > > library=/usr/lib64/p11-kit-proxy.so > > name=p11-kit-proxy > > NSS=trustOrder=100 > > You shouldn't need that bit. It was only pam_pkcs11 which wasn't loading > the smartcard modules via the nssdb, and it wants to load OpenSC > *explicitly* anyway. And besides, *nothing* should be > using /etc/pki/nssdb since we can ditch the Shared System Database > nonsense. Just let use pam_pkcs11 use its default /etc/pam_pkcs11/nssdb > instead.
Well,not really, it turns out that the gnome-settings-daemon loads the opensc-module directly from /etc/pki/nssdb. So if I don't import the opensc-module in there, gnome-settings-daemon wont recognize inserts/removals. I choosed to import the p11-kit-proxy instead of opensc-module directly because then I got the 'system trust' as well automatically. If I'm not missing something here of course (which very well might be the case since this is *a hassle*). > > $> rm -rf ~/.pki/nssdb/* > > $> rm -rf ~/.mozilla/firefox/*.default/{cert4*,key4*,pkcs11.txt} > > $> rm -rf ~/.local/share/keyrings > > > > Log out, log in again. > > Are you logging in with password or smartcard? I'm logging in with smartcard. > You may be hitting a slightly unrelated issue with the GNOME keyring, > which is that it uses the system password to encrypt its own storage. > That's how it can support the 'protected authentication path' where the > PKCS#11 client doesn't actually need to *give* it a password — it's > already *got* one by stealing it from the PAM stack as you log in. > > However, if you log in using pam_pkcs11 then GNOME keyring doesn't have > a password and can't unlock itself. So the first time it's used it's > *going* to ask for a password. Even in a well-behaved application like > Firefox which *can* support the protected auth path. And even when > you're using its non-PKCS#11 functions. Ok, that may be the case. I was under the impression though that GKR had sat its password to my PIN (changing the PIN code will actually result in a dialog where it's asking me for my password at login time, since it can't unlock my GKR). However as I'm typing this I'm pretty sure that is for the "Login"-keyring and *not* GKR (because they are not the same right ?). In seahorse i have a structure like this, Passwords, - Login PGP - GnuPG Keys Certificates - Instantd IED IP9 (Smartcard token) - Gnome2 Keyring - System Trust - Default Trust Secure Shell - OpenSSH keys And as I said, I'm *pretty sure that the "Login keyring" has the same password as my PIN, whereas "Gnome2 Keyring" doesn't seem to have one at all in the beginning, which would then make sense. Wouldn't the right thing to do be to set it the same way the "Login keyring" does ? > This is theoretically fixable — if you have the smartcard present for > login, GKR ought to be able to use *its* key for decrypting the storage. > (When authenticating with pam_winbind against Active Directory we have > similar issues for which we want to use the BackupKey Remote Protocol to > provide a key: https://bugzilla.samba.org/show_bug.cgi?id=9979 ) > > > And in my casse, *both* evolution and firefox asks me for, > > - First Password to my "Gnome2 Key Storage", > > - When entered, next dialog sows up, "Enter Password to unlock the > > certificate/Key storage" (and the option to automatically unlock it > > whenever I'm logged in" > > - When entered, next dialog pops up, "Enter the password for secret store" > > > > (screenshots attached). > > > > So basically, at least for me, none of the applications does the right > > thing,. > > Evolution prints the following when running from the terminal, "WARNING: > > gnome-keyring:: C_Initialize called twice for same process" which doesn't > > seem right. > > You've loaded it twice. You didn't need to add it > to /etc/pki/nssdb/pkcs11.txt when everything *except* pam_pkcs11 was > already loading it for themselves. Well, see my comment about that above. But I hear you. Maybe the "best thing" thing here would be to add opensc-pkcs11 and p11-kit-trust to /etc/pki/nssdb. Even though as you say, it shouldn't be necessary, but I would like to state otherwise (since gnome-settings-daemon doesn't work correctly without the opensc module in there). But, that's probably because of, 1 ) a bug in gnome-settings-daemon how the initialization of nssdb is done, 2 ) me missing something about how gnome-settings-daemon initializes "smartcard-stuff" > > So, what we ended up with is two module-files under /etc/pkcs11/modules, > > $> cat gnome-keyring.module > > # The file is installed/loaded from the default module p11-kit directory > > module: gnome-keyring-pkcs11.so > > disable-in: evolution, google-chrome, firefox, thunderbird > > If you fix the unlock-at-login issue then you shouldn't have to disable > this in any application for which there isn't already a "Does not > support Protected Authentication Path" bug filed. I.e. evolution. Yep, I hear you. But since we use rhel7 I doubt those patches will be in anytime soon. So to not confuse the users, I think I'll need to do just that. > > # And where to store and lookup trust objects > > x-trust-store: > > pkcs11:library-manufacturer=GNOME%20Keyring;serial=1:XDG:DEFAULT > > x-trust-lookup: pkcs11:library-manufacturer=GNOME%20Keyring > > > > $> cat opensc.module > > module:/usr/lib64/opensc-pkcs11.so > > enable-in: firefox, thunderbird, evolution, chrome, gnome-settings-daemon, > > modutil, seahorse > > I'm not sure why you added that 'enable-in' line. This ought to have > been find in all applications, surely? Except pam_pkcs11 but see above. Yea, well I tried to solve it this way since I needed to import p11-kit-proxy into /etc/pki/nssdb so that gnome-settings-daemon would work. And using, disable : pam_pkcs11, login instead worked, but i never got gnome-settings-daemon/screensaver/gdm to ignore the loading of the module (probably because of fishy process names that I couldn't get right), that's why i went with the enable-in: instead. YIKES. This isn't to easy. Really appreciate all help though! Best regards, Patrik Martinsson, Sweden -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto