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
