On Mon, 2014-12-08 at 16:59 +0000, David Woodhouse wrote: > On Mon, 2014-12-08 at 16:44 +0000, Martinsson Patrik wrote: > > 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*). > > Anything needing system trust will be loading libnssckbi.so explicitly, > do doesn't need you to add it to any secmod.db/pkcs11.txt.
Yea, well I would say that gsd explicity load /etc/pki/nssdb, in the file plugins/smartcard/gsd-smartcard-manager.c there's a function called "load_nss" that handles exactly that part. And running gsd in debugmode, you'll see something like this, (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: attempting to load NSS database '/etc/pki/nssdb' (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: NSS database '/etc/pki/nssdb' loaded (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: taking name org.gnome.SettingsDaemon.Smartcard on session bus (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: Getting list of suitable drivers (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: Activating driver 'OpenSC PKCS #11 Module' (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: watching for smartcard events (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: Detected slot -1 is empty in reader (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: Detected smartcard insertion event in slot 1 (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: =============================== (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: Token 'My token' (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: Inserted: yes (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: Previously used to login: yes (gnome-settings-daemon:16246): smartcard-plugin-DEBUG: =============================== So, If I don't have opensc-module, one way or another in (sql):/etc/pki/nssdb I will loose all functionality that gsd brings me, for example "lock screen at card removal". If this implementation is wrong and should be done in another way I cannot answer for. I just know what works and what doesn't. > > > 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). > > Hm, OK. Maybe it is. I can see how that would work with the way it > 'steals' the password from the PAM stack. I would imagine that it's > using the same password for *all* its storage, rather than different > passwords. So perhaps just ignore my suggestion; it's probably not that. > > > > > 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 ) > > > So here are my observations from an "first login time user", I've done this multiple times with new profiles, and it's the same behavior every time, maybe there is a logical reason for these behavior , but it's seems rather fishy to me. - I've now verified that both the "Login" keyring and the "gnome2 key storage" gets my PIN as password when logging in the first time. This is fine, I like this approach. However, only the "Login" keyring get's unlocked when logging in. And, how do we handle the "keyring-passwords" when a user changes it's PIN ? - First thing I did was to open up seahorse, to my surprise the "Gnome2 Key Storage" wasn't there. However, ls -la ~/.local/share/keyrings shows both "login.keyring" and "user.keystore". Logging out and loggin in again, and the "Gnome2 Key Storage" is now visible in seahorse. - If the "Gnome2 Key Storage" isn't unlocked Firefox will indeed ask me for credentials to it when visiting a site requiring my smart card. Firefox will ask me every time until I check the box, "Automatically unlock at login", if I've checked this box, Firefox will never ask me again. Interesting note is that, visiting a site that requires smart card, and when the "Gnome2 Key Storage" keyring isn't unlocked, you can't get out of that prompt until you have provided the right password for "Gnome2 Key Storage". If you just hit cancel, the prompt comes back (and it blocks me from interacting with anything else on the desktop). So basically what I'm saying is that there is no way out from that situation if you don't (for whatever reason) know the password to your "Gnome2 Key Storage"-keyring. This seems definitly as a dangerous situation, seems to me like the right thing to do is just "cancel whatever we were doing" if the user presses cancel. - Evolution will ask me every time for the "Gnome2 Key Storage"-keyring, this is probably due to the bug you filed and fixed. It doesn't matter if the keyring is unlocked or not, but as stated, this is probably because of the bug. - When logging in for the first time, both "login.keyring" and "Gnome2 Key Storage"-keyring are created. However, only the "login.keyring" is beeing automatically unlocked per default (it will unlock automatically if I check that box when entering a password to it). I wonder though if it wouldn't be the right thing to unlock that keyring as well when logging in. And, where does this "Automatically unlock at login"-setting beeing saved, I cannot seem to find it anywhere (I'm just curios how I manually can handle this without the gui). > > > > 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" > > Screw it, just delete /usr/share/p11-kit/modules/gnome-keyring.module - What is "Gnome2 Key Storage"-kerying anyway, what is it actually used for. Everything seems end up in "Login"-keyring anyway ? I'm confused. > You didn't actually want to *use* it for PKCS#11 anyway. - Isn't there a reason for gnome-kering.module to be a pkcs11 module you mean ? > > 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" > > What exactly is the issue with gnome-settings-daemon? What's it supposed > to do with the smartcard? I can't see *any* reference to /etc/pki/nssdb > in its source code at first glance... See my answer in the beginning. > We should probably file a bug for that. If OpenSC is there in the > system's p11-kit configuration, it should be seen by > gnome-settings-daemon. I know that NSS applications are often > second-class citizens in this respect but a GNOME application *needs* to > do the right thing even if it has to jump through extra hoops (or get > ported to GnuTLS) in order to do so. > > I still maintain that the path to sanity involves killing /etc/pki/nssdb > entirely, and then you can look at applying *correct* fixes to > whatever's still not behaving correctly. /Me is getting more confused for every day that passes ;) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
