Re: libnsssysinit
On Tue, 2014-12-09 at 14:18 +, Martinsson Patrik wrote: It's cute that GNOME keyring can provide PKCS#11 functionality and you can store certificates and keys in there. But you aren't *using* that functionality. So just unregister the module entirely by deleting its file from /usr/share/p11-kit/modules/. Then you don't have to worry about its behaviour, or the apps which don't support the protected authentication path. Life's too short :) Haha, ok. I get that part. What I don't get is, why is it there, and when is, and who is suppose to use it Shouldn't it be removed ? FWIW this isn't even working correctly in Firefox. It *sometimes* handles CKF_PROTECTED_AUTHENTICATION_PATH correctly, but other times it just starts a new session, doesn't bother to log in, gets CKR_USER_NOT_LOGGED_IN from C_SignInit() and fails. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1110233 -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Mon, 2014-12-08 at 13:53 -0800, Robert Relyea wrote: Nothing in the above paragraph is true. openning 1)sql:/etc/pki/nssdb is *STILL* the recommended action for applications (whether or not nssysinit is installed), and Recommended in the sense of do as I say, not as I do, of course :) Without nsssysinit, using sql:/etc/pki/nssdb give you a read-only database, which isn't acceptable for most applications. Hence the logic in Evolution which is: if /etc/pki/nssdb/pkcs11.txt contains 'library=libnsssysinit.so' then open sql:/etc/pki/nssdb else open sql:$HOME/.pki/nssdb That logic is *horrid*, and I really didn't want it. But when I asked about it here, no better suggestions were forthcoming. Now I wish I'd just given up on the Shared System Database sooner, since p11-kit-trust fixes it *properly* anyway. Other applications just don't use /etc/pki/nssdb at all. What are the major NSS-using applications? - Chrome uses sql:$HOME/.pki/nssdb and not /etc/pki/nssdb. - Firefox is even worse and uses a *private* database. - Thunderbird (IIRC) is the same as Firefox. Except a *different* private database, of course. Did I miss any that actually *do* use sql:/etc/pki/nssdb according to the recommendation? 2) what ever the recommendation, pam_pkcs11 still used /etc/pki/nssdb (by default, always), not /etc/pams_pkcs11/nssdb. (It never has used). Ah yes, the Fedora default pam_pkcs11.conf does indeed set nss_dir=/etc/pki/nssdb (*not* sql:/etc/pki/nssdb, which is presumably a bug). But if there is no such setting in the config file, the default is /etc/pam_pkcs11/nssdb. Or strictly speaking, CONFDIR /nssdb as set at line 62 of src/pam_pkcs11/pam_config.c. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Mon, 2014-12-08 at 13:56 -0800, Robert Relyea wrote: On 12/08/2014 08:59 AM, David Woodhouse wrote: 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. The whole point of /etc/pki/nssdb is so you have one place to install stuff. Well, kind of. Except that for system-trusted CAs, there is *already* one place to install stuff. That's libnssckbi.so. And with the native NSS version of that library dropped, and a symlink in place to p11-kit-trust.so, we have this working *properly* in line with the sysadmin's choices for which CAs to trust. As you reminded me, applications choose to open libnssckbi.so *if* they want the system trust. So it's important that we have one place for it. The Shared System Database approach, with *some* CAs in libnssckbi.so and *some* installed by the sysadmin into sql:/etc/pki/nssdb means that the application's *choice* of whether to load the trusted CAs is confused. If they choose *not* to load libnssckbi.so they might get *some* trusted CAs from sql:/etc/pki/nssdb anyway. And for additional PKCS#11 modules there's *already* one place for those too. If I install the OpenSC package, it'll automatically drop a file into /usr/share/p11-kit/modules/ and well-behaved applications will automatically see it. We just need to make NSS applications behave well — and yes, adding p11-kit-proxy.so to /etc/pki/nssdb/pkcs11.txt *might* be part of the approach there. Although you don't want the trust modules in that case, since *those* come through the libnssckbi.so symlink to p11-kit-trust.so. It's the default for anything that I've had a say in and will continue to be the default. That's OK. We just need to work out how to make it *work* :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Mon, 2014-12-08 at 16:59 +, David Woodhouse wrote: On Mon, 2014-12-08 at 16:44 +, 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
Re: libnsssysinit
On Tue, 2014-12-09 at 13:15 +, Martinsson Patrik wrote:
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.
Not sql:/etc/pki/nssdb; this is another one that that uses the legacy
database format in /etc/pki/nssdb instead. Just to add to the fun :)
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.
If it's not honouring the p11-kit configuration, then it's broken. I
filed https://bugzilla.gnome.org/show_bug.cgi?id=741293
Yes, adding OpenSC (or p11-kit-proxy) to /etc/pki/nssdb/secmod.db will
help to work around the problem.
- 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.
I don't. Your certificate is two-factor authentication — a combination
of something you have (the smartcard itself), and something you know (a
PIN).
Some people might have a trivial PIN such as 123456 on their device on
the basis that the PIN is useless without the device itself. Or no PIN
at all.
Using the PIN *alone* as the encryption key for your secrets (or your
whole home directory, in the case of ecryptfs which is going to do
something similar) is a *BAD* idea.
But we digress... :)
- 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
?
It's cute that GNOME keyring can provide PKCS#11 functionality and you
can store certificates and keys in there. But you aren't *using* that
functionality. So just unregister the module entirely by deleting its
file from /usr/share/p11-kit/modules/. Then you don't have to worry
about its behaviour, or the apps which don't support the protected
authentication path. Life's too short :)
/Me is getting more confused for every day that passes ;)
Yeah, this stuff is painful, but thanks for helping us work through it.
We *really* need to get to a point where all applications in a system
will *consistently* use the PKCS#11 modules configured in p11-kit,
regardless of which crypto library they're using. And all command-line
references to certificates/keys will accept PKCS#11 URLs as well as
filenames.
Precisely *how* NSS gets there, it doesn't really matter — whether it's
adding p11-kit-proxy.so to {sql:,}/etc/pki/nssdb by default and actually
making applications *use* that directory (qv.), or by symlinking
libnssckbi.so to p11-kit-proxy.so or actually adding proper *native*
support for p11-kit for loading the right modules at the right time.
With p11-kit-trust we have made great progress — at least we can now
have a consistent trust database, maintained by the sysadmin and
reliably used by *every* application that needs it. Next we need to sort
out the rest of the story...
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Tue, 2014-12-09 at 13:54 +, David Woodhouse wrote:
On Tue, 2014-12-09 at 13:15 +, Martinsson Patrik wrote:
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.
Not sql:/etc/pki/nssdb; this is another one that that uses the legacy
database format in /etc/pki/nssdb instead. Just to add to the fun :)
Well, pam_pkcs11.conf states /etc/pki/nssdb by default, however I
changed mine to sql: since I figured that was the new way to go, even
if it doesn't matter. I was trying to be consistent since I export
NSS_DEFAULT_DB_TYPE globally. I'm aware of the the new and the old
nssdb format, what I don't understand though is why a distribution such
as Rhel 7 doesn't default to the new database format (and making sure
that every application that used the old now uses the new). But maybe
the focus lies on changing from nss to p11-kit, what do I know.
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.
If it's not honouring the p11-kit configuration, then it's broken. I
filed https://bugzilla.gnome.org/show_bug.cgi?id=741293
Great!
Yes, adding OpenSC (or p11-kit-proxy) to /etc/pki/nssdb/secmod.db will
help to work around the problem.
- 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.
I don't. Your certificate is two-factor authentication — a combination
of something you have (the smartcard itself), and something you know (a
PIN).
Some people might have a trivial PIN such as 123456 on their device on
the basis that the PIN is useless without the device itself. Or no PIN
at all.
Using the PIN *alone* as the encryption key for your secrets (or your
whole home directory, in the case of ecryptfs which is going to do
something similar) is a *BAD* idea.
But we digress... :)
Well, that's a really good point. Didn't even think of it. But from a
user-perspective, I definitely would say that you don't wont to be
bothered by unlocking some keyring after I've logged in. Maybe the
password for the keyring could be based off your PIN but obscured by
some way (security by obscurity). I do though, as said, understand the
issue here - when you brought it up =)
- 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 ?
It's cute that GNOME keyring can provide PKCS#11 functionality and you
can store certificates and keys in there. But you aren't *using* that
functionality. So just unregister the module entirely by deleting its
file from /usr/share/p11-kit/modules/. Then you don't have to worry
about its behaviour, or the apps which don't support the protected
authentication path. Life's too short :)
Haha, ok. I get that part. What I don't get is, why is it there, and
when is, and who is suppose to use it Shouldn't it be removed ?
/Me is getting more confused for every day that passes ;)
Yeah, this stuff is painful, but thanks for helping us work through it.
We *really* need to get to a point where all applications in a system
will *consistently* use the PKCS#11 modules configured in p11-kit,
regardless of which crypto library they're using. And all command-line
references to certificates/keys will accept PKCS#11 URLs as well as
filenames.
I hear you. It seems like we are on the way. From what I understand I
think that NetworkManager is also taking that approach, which would be a
really good thing. https://wiki.gnome.org/Projects/NetworkManager/PKCS11
Precisely *how* NSS gets there, it doesn't really matter — whether it's
adding p11-kit-proxy.so to {sql:,}/etc/pki/nssdb by default and actually
making applications *use* that directory (qv.), or by symlinking
libnssckbi.so to p11-kit-proxy.so or actually adding proper *native*
support for p11-kit for loading the right modules at the right time.
With p11-kit-trust we have made great progress — at least we can now
have a consistent trust database, maintained by the sysadmin and
reliably used by *every* application that needs it. Next we need to sort
out the rest of the story...
Yes, definitely. Basically all I wanted to do, as stated earlier, was
to, trust our ca, and make 'various user applications' make use of the
opensc-module. Turned out to be harder than I thought, but now we are
there and I've got a lot more insight in this matter.
Again, thanks for all the help and explanations.
/Patrik
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Tue, 2014-12-09 at 14:18 +, Martinsson Patrik wrote: On Tue, 2014-12-09 at 13:54 +, David Woodhouse wrote: On Tue, 2014-12-09 at 13:15 +, Martinsson Patrik wrote: 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. Not sql:/etc/pki/nssdb; this is another one that that uses the legacy database format in /etc/pki/nssdb instead. Just to add to the fun :) Well, pam_pkcs11.conf states /etc/pki/nssdb by default, however I changed mine to sql: since I figured that was the new way to go, even if it doesn't matter. I was trying to be consistent since I export NSS_DEFAULT_DB_TYPE globally. I'm aware of the the new and the old nssdb format, what I don't understand though is why a distribution such as Rhel 7 doesn't default to the new database format (and making sure that every application that used the old now uses the new). The problem is that NSS-based applications are wildly uncoordinated. As discussed in my response to Bob earlier, even the in-house apps like Firefox and Thunderbird are doing entirely the wrong thing. There have been bugs filed for years, and there seems to be very little prospect of them getting fixed any time soon. It *would* be good if a progressive distribution would do a bombing run on applications and fix them all to Do The Right Thing. If we can just agree on precisely what that is :) Using the PIN *alone* as the encryption key for your secrets is a *BAD* idea. Well, that's a really good point. Didn't even think of it. But from a user-perspective, I definitely would say that you don't wont to be bothered by unlocking some keyring after I've logged in. Maybe the password for the keyring could be based off your PIN but obscured by some way (security by obscurity). I do though, as said, understand the issue here - when you brought it up =) You have a key on the smartcard. Use *that* to decrypt the 'session' key that's actually used to decrypt the storage. This is now https://bugzilla.gnome.org/show_bug.cgi?id=741247 It's basically the same problem as I am logging in using a network password, and the password might change on the network. The hooks that GNOME keyring has into the PAM stack work fine for handling the case of a *local* password, when you change that password locally using passwd(8). Other use cases need a little more love. It's cute that GNOME keyring can provide PKCS#11 functionality and you can store certificates and keys in there. But you aren't *using* that Haha, ok. I get that part. What I don't get is, why is it there, and when is, and who is suppose to use it Shouldn't it be removed ? No, because we are moving in the direction where it *will* be used. As soon as we've consistently got all applications *using* the modules that p11-kit has configured, people want to discourage the use of *files* for certificates and keys, and instead have them stored in the GNOME keyring soft token. It's tied in with the NetworkManager PKCS#11 support that you mentioned. But we aren't there yet, which is why you can disable it for now without worrying. Yes, definitely. Basically all I wanted to do, as stated earlier, was to, trust our ca, and make 'various user applications' make use of the opensc-module. Turned out to be harder than I thought, but now we are there and I've got a lot more insight in this matter. Right. The trust our CA bit is at least fairly much fixed. The work which has already been done with p11-kit-trust and making sure p11-kit-trust is *used* in all applications, has paid off. Getting applications to consistently benefit from the p11-kit configuration for which PKCS#11 modules to use is still a work in progress, as you've found... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Mon, 2014-12-08 at 10:15 +, 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.
$ 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?
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.
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.
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.
# 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.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Mon, 2014-12-08 at 13:05 +, David Woodhouse wrote: 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. I just fixed Evolution, FWIW: https://bugzilla.gnome.org/show_bug.cgi?id=741059#c1 -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Mon, 2014-12-08 at 13:05 +, David Woodhouse wrote:
On Mon, 2014-12-08 at 10:15 +, 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
Re: libnsssysinit
On 12/08/2014 05:05 AM, David Woodhouse wrote: On Mon, 2014-12-08 at 10:15 +, 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. Nothing in the above paragraph is true. openning 1)sql:/etc/pki/nssdb is *STILL* the recommended action for applications (whether or not nssysinit is installed), and 2) what ever the recommendation, pam_pkcs11 still used /etc/pki/nssdb (by default, always), not /etc/pams_pkcs11/nssdb. (It never has used). smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On 12/08/2014 08:59 AM, David Woodhouse wrote: 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. The whole point of /etc/pki/nssdb is so you have one place to install stuff. It's the default for anything that I've had a say in and will continue to be the default. bob smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
Hi again David (and everyone else),
Thanks again for all the explanations, it certainly (again) makes stuff
clearer and I now seem to have an reasonable idea about whats going on
and how to handle our situation.
On a standard Rhel 7 installation, the pkcs11.txt under /etc/pki/nssdb
*only* contains,
library=libnsssysinit.so
name=NSS Internal PKCS #11 Module
parameters=configdir='.' certPrefix='' keyPrefix='' secmod='' flags=
updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid=''
updateTokenDescription=''
NSS=Flags=internal,moduleDBOnly,critical trustOrder=75 cipherOrder=100
slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512]
askpw=any timeout=30})
And this is a good thing as it will dynamically load the users
~/.pki/nssdb in read-write mode on top of the read-only /etc/pki/nssdb
so users can set up their on trusts etc., correct ?
If I then use 'pkcs11_inspect debug' for verifying my self-signed
certificate (and having the CA's certificate
under /etc/pki/ca-trust/source/anchors/ update-ca-trust) the
verifcation *fails*.
If I then add the following lines to /etc/pki/nssdb/pkcs11.txt
library=libnssckbi.so
name=libnssckbi
NSS=trustOrder=100
(and libnssckbi.so points to alternatives, which points to
p11-kit-trust).
You say that this shouldn't be necessary (and probably a bug), just to
clarify things for me, do you mean that,
1 ) adding the libnssckbi.so to shouldn't be necessary since it should
already be there from the beginning, and that the bug is that the
library is missing from the default setup, or
2 ) the module shouldn't need to be in the nssdb at all since this
should be handled in some other way (please expand on that part if that
's the case)
Now the libp11-proxy,
I worked around it by symlinking /usr/lib64/libnssckbi.so to
p11-kit-proxy.so instead of p11-kit-trust.so, which gives me the trust
roots *and* the other loaded modules. That one probably ought to be
the default.
Ok, I did the same thing. Using the alternatives system.
Firefox only asks me to log into my p11-kit-provided hardware tokens
when I go to a web site which wants a certificate, which is fair
enough.
Yes, same behavior here, I was mistaken when I stated that it actually
asked for pins to GNOME keyring and the Secret Store.
Firefox behaves in my opinion as expected, and I don't need to manually
mess with the users nssdb - the default will just work as I expect
(trusting my CA and ask for PIN to hardware token when requested).
Evolution does ask for a PIN for GNOME keyring and the Secret Store.
Stef suggests that's because Evolution doesn't handle
CKF_PROTECTED_AUTHENTICATION_PATH. I filed this bug for that:
https://bugzilla.gnome.org/show_bug.cgi?id=741059
Cool, then we have the same behavior and a possible reason for why it
behaves like it does. The same thing goes for chrome, I'll file a
bug-report to those ppl referring to this bug.
Now, the interesting thing, it seems (at least to me in my setup) that
having a system where,
- libnssckbi.so - alternatives - p11-kit-proxy.so
- /etc/pki/nssdb/pkcs11.txt contains,
library=libnsssysinit.so
name=NSS Internal PKCS #11 Module
parameters=configdir='.' certPrefix='' keyPrefix='' secmod='' flags=
updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid=''
updateTokenDescription=''
NSS=Flags=internal,moduleDBOnly,critical trustOrder=75 cipherOrder=100
slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512]
askpw=any timeout=30})
library=libnssckbi.so
name=libnssckbi
NSS=trustOrder=100
breaks pam_pkcs11. Using the above config, pkcs11_inspect throws the
following,
DEBUG:pam_config.c:238: Using config
file /etc/pam_pkcs11/pam_pkcs11.conf
DEBUG:pkcs11_lib.c:182: Initializing NSS ...
DEBUG:pkcs11_lib.c:192: Initializing NSS ... database=sql:/etc/pki/nssdb
DEBUG:pkcs11_lib.c:210: ... NSS Complete
DEBUG:pkcs11_inspect.c:69: loading pkcs #11 module...
DEBUG:pkcs11_lib.c:222: Looking up module in list
DEBUG:pkcs11_lib.c:225: modList = 0xa4bb70 next = 0x108fe50
DEBUG:pkcs11_lib.c:226: dllName= null
DEBUG:pkcs11_lib.c:225: modList = 0x108fe50 next = 0x0
DEBUG:pkcs11_lib.c:226: dllName= libnssckbi.so
DEBUG:pkcs11_lib.c:272: loading Module explictly,
moduleSpec=library=/usr/lib64/pkcs11/opensc-pkcs11.so
name=SmartCard module=/usr/lib64/pkcs11/opensc-pkcs11.so
DEBUG:pkcs11_lib.c:276: Failed to load SmartCard software (null)
ERROR:pkcs11_inspect.c:73:
load_pkcs11_module(/usr/lib64/pkcs11/opensc-pkcs11.so) failed:
Not really sure why this happens, but changing the lines,
library=libnssckbi.so
name=libnssckbi
NSS=trustOrder=100
to explicitly load p11-kit-trust (instead of loading it through the
p11-kit-proxy),
library=/usr/lib64/pkcs11/p11-kit-trust.so
name=libnssckbi
NSS=trustOrder=100
works as expected.
Any thoughts on why ?
I don't mind having the /etc/pki/nssdb/pkcs11.txt load
the
Re: libnsssysinit
On Thu, 2014-12-04 at 11:31 +, David Woodhouse wrote: That one. libnssckbi.so is what provides the default trust roots. It's *always* supposed to be loaded in an NSS system. You shouldn't need to add it manually. I don't. ... except in the specific case where I was testing pam_pkcs11. https://bugzilla.redhat.com/show_bug.cgi?id=1170587 -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On 12/04/2014 03:31 AM, David Woodhouse wrote: You say that this shouldn't be necessary (and probably a bug), just to clarify things for me, do you mean that, 1 ) adding the libnssckbi.so to shouldn't be necessary since it should already be there from the beginning, and that the bug is that the library is missing from the default setup, or That one. libnssckbi.so is what provides the default trust roots. It's *always* supposed to be loaded in an NSS system. You shouldn't need to add it manually. I don't. Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application. I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in? bob (Note that you also shouldn't need to add your CAs to the actual sqlite database in /etc/pki/nssdb either, since they should be coming from your libnssckbi.so which is actually p11-kit.) Now the libp11-proxy, I worked around it by symlinking /usr/lib64/libnssckbi.so to p11-kit-proxy.so instead of p11-kit-trust.so, which gives me the trust roots *and* the other loaded modules. That one probably ought to be the default. Ok, I did the same thing. Using the alternatives system. Firefox only asks me to log into my p11-kit-provided hardware tokens when I go to a web site which wants a certificate, which is fair enough. Yes, same behavior here, I was mistaken when I stated that it actually asked for pins to GNOME keyring and the Secret Store. Firefox behaves in my opinion as expected, and I don't need to manually mess with the users nssdb - the default will just work as I expect (trusting my CA and ask for PIN to hardware token when requested). Did you have to manually add libnssckbi to Firefox too? Remember, that uses its own database and not sql:/etc/pki/nssdb. Evolution does ask for a PIN for GNOME keyring and the Secret Store. Stef suggests that's because Evolution doesn't handle CKF_PROTECTED_AUTHENTICATION_PATH. I filed this bug for that: https://bugzilla.gnome.org/show_bug.cgi?id=741059 Cool, then we have the same behavior and a possible reason for why it behaves like it does. The same thing goes for chrome, I'll file a bug-report to those ppl referring to this bug. Chrome uses sql:$HOME/.pki/nssdb and not sql:/etc/pki/nssdb. Did you add libnssckbi.so to *that* one? (Evolution will use sql:/etc/pki/nssdb *if* it's enabled, and sql:$HOME/.pki/nssdb if not. A piece of horridness fundamental to the design of the NSS Shared System Database.) breaks pam_pkcs11. Using the above config, pkcs11_inspect throws the following, ... DEBUG:pkcs11_lib.c:272: loading Module explictly, moduleSpec=library=/usr/lib64/pkcs11/opensc-pkcs11.so name=SmartCard module=/usr/lib64/pkcs11/opensc-pkcs11.so DEBUG:pkcs11_lib.c:276: Failed to load SmartCard software (null) ERROR:pkcs11_inspect.c:73: load_pkcs11_module(/usr/lib64/pkcs11/opensc-pkcs11.so) failed: Not really sure why this happens, but changing the lines, I suspect this is because it's trying to explicitly load opensc-pkcs11.so when it was *already* loaded. I wonder if works better if you point it at p11-kit-proxy.so instead. Not sure if that can cope better with multiple initialisations, if such a thing is even possible. Further discussion of that might be more appropriately targeted to the OpenSC mailing list, since pam_pkcs11 is theirs too. In the meantime, given the bug that libnssckbi.so doesn't seem to show up for you unless explicitly requested, a potential workaround might be to point pam_pksc11 at a NSS DB which *doesn't* request it (it can request p11-kit-trust.so instead). smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote: That one. libnssckbi.so is what provides the default trust roots. It's *always* supposed to be loaded in an NSS system. You shouldn't need to add it manually. I don't. Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application. OK... but applications such as firefox which actually want trust to work should be loading it, right? Yes, there are some applications which use NSS only for private crypto purposes and don't need the trust roots, but Patrik seemed to be suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until he manually added it to pkcs11.txt/secmod.db. I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in? I thought we really were just replacing libnssckbi.so with our own. Which is fine as long as it's actually being loaded. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
Yes, there are some applications which use NSS only for private crypto purposes and don't need the trust roots, but Patrik seemed to be suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until he manually added it to pkcs11.txt/secmod.db. Maybe I should have been clearer from the beginning, it was actually just pam_pkcs11 that didn't automatically picked up my CA, sorry if it got confusing. /Patrik Sent from Ninehttp://www.9folders.com/ From: David Woodhouse dw...@infradead.org Sent: Dec 4, 2014 11:02 PM To: Robert Relyea Cc: dev-tech-crypto@lists.mozilla.org Subject: Re: libnsssysinit On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote: That one. libnssckbi.so is what provides the default trust roots. It's *always* supposed to be loaded in an NSS system. You shouldn't need to add it manually. I don't. Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application. OK... but applications such as firefox which actually want trust to work should be loading it, right? Yes, there are some applications which use NSS only for private crypto purposes and don't need the trust roots, but Patrik seemed to be suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until he manually added it to pkcs11.txt/secmod.db. I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in? I thought we really were just replacing libnssckbi.so with our own. Which is fine as long as it's actually being loaded. -- dwmw2 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On 12/04/2014 02:00 PM, David Woodhouse wrote: On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote: That one. libnssckbi.so is what provides the default trust roots. It's *always* supposed to be loaded in an NSS system. You shouldn't need to add it manually. I don't. Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application. OK... but applications such as firefox which actually want trust to work should be loading it, right? firefox loads libnssckbi.so only if not other 'Root Certs Module' has been loaded. the pk11-kit module is a Root Certs Module, so if it's been loaded, then libnssckbi.so isn't. Yes, there are some applications which use NSS only for private crypto purposes and don't need the trust roots, but Patrik seemed to be suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until he manually added it to pkcs11.txt/secmod.db. I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in? I thought we really were just replacing libnssckbi.so with our own. Which is fine as long as it's actually being loaded. Sort of, It's not the same name, it's a different module, but it has the same attributes. bob smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Tue, 2014-12-02 at 20:30 +, David Woodhouse wrote: On Tue, 2014-12-02 at 19:59 +, David Woodhouse wrote: That doesn't happen here on F21, FWIW. Firefox only asks me to log into my p11-kit-provided hardware tokens when I go to a web site which wants a certificate, which is fair enough. And I haven't actually got Evolution to show me any hard evidence that they're loaded at all. I'll have to put a S/MIME certificate onto one of them and see if that works. There's something weirder going on here. Whenever I start an application (even after disabling the p11-kit replacement for libnssckbi.so) it seems to forcibly *remove* p11-kit-proxy from the modules list. I can get Firefox to use p11-kit-proxy.so but only for one run at a time having manually added it through the GUI. I'm fairly sure that's a recent regression; I tried this once before and it was basically working. I'll quit following up to myself now but two more observations first: I filed a bug for the above observation that the added module gets removed when I start applications: https://bugzilla.redhat.com/1169953 I worked around it by symlinking /usr/lib64/libnssckbi.so to p11-kit-proxy.so instead of p11-kit-trust.so, which gives me the trust roots *and* the other loaded modules. That one probably ought to be the default. Firefox only asks for the PIN for the hardware tokens. Evolution does ask for a PIN for GNOME keyring and the Secret Store. Stef suggests that's because Evolution doesn't handle CKF_PROTECTED_AUTHENTICATION_PATH. I filed this bug for that: https://bugzilla.gnome.org/show_bug.cgi?id=741059 -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Mon, 2014-12-01 at 17:22 -0800, Robert Relyea wrote: This is still the issue with nsssysinit. It currently only works if the the application open sql:/etc/pki/nssdb. Currently firefox doesn't even use the sql database. Which has always been a bit of a facepalm realisation: Hey... we provide this useful way of having a system database. Oh, but we don't use it *ourselves*. That would be too cunning. I was interested in nsssysinit once but I've mostly given up on it now. It has largely been superseded by p11-kit-trust, which in the NSS case provides a replacement for libnssckbi.so and gives us consistency across the entire system regardless of the crypto libraries in use. (This wasn't in RHEL6; it came in with Fedora 19 so hopefully it's in RHEL7). For smartcards though (or indeed just general desktop integration and using the PKCS#11 services from things like GNOME Keyring), NSS is still lagging behind. With p11-kit it's trivial for PKCS#11 modules just to register themselves by dropping a file into /usr/share/p11-kit/modules, and then they Just Work™ in every tool and application which is p11-kit aware. If you install the OpenSC package, for example, it'll do just that. As does gnome-keyring. Unfortunately, it works for everything *except* applications using NSS. We should probably make NSS load the p11-kit configured modules automatically, and then it'll be a first-class citizen on a modern Linux system again. There is p11-kit-proxy.so which is a single module that *proxies* all the configured modules in different slots, which makes that slightly easier... $ modutil -dbdir sql:`pwd` -add p11-kit-proxy -libfile /usr/lib64/p11-kit-proxy.so WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q enter' to abort, or enter to continue: Module p11-kit-proxy added to database. $ modutil -list -dbdir sql:`pwd` 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 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: Feitian SCR301 00 00 token: Red Key (User PIN) slot: Yubico Yubikey NEO CCID 01 00 token: PIV_II (PIV Card Holder pin) --- -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
Hello, It has largely been superseded by p11-kit-trust, which in the NSS case provides a replacement for libnssckbi.so and gives us consistency across the entire system regardless of the crypto libraries in use. (This wasn't in RHEL6; it came in with Fedora 19 so hopefully it's in RHEL7). FWIW this is also available in RHEL ≥ 6.5, but you have to opt in via (update-ca-trust enable). Mirek -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Tue, 2014-12-02 at 11:16 -0500, Miloslav Trmač wrote: Hello, It has largely been superseded by p11-kit-trust, which in the NSS case provides a replacement for libnssckbi.so and gives us consistency across the entire system regardless of the crypto libraries in use. (This wasn't in RHEL6; it came in with Fedora 19 so hopefully it's in RHEL7). FWIW this is also available in RHEL ≥ 6.5, but you have to opt in via (update-ca-trust enable). Great. So that should solve Patrik's CA issues without needing to do anything special. All that remains is to get the smartcards working by loading p11-kit-proxy.so (or preferably the individual modules) too. Is that something we could do in the p11-kit-trust implementation of libnssckbi.so without having to add another hook? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
Hello,
- Original Message -
On Tue, 2014-12-02 at 11:16 -0500, Miloslav Trmač wrote:
Hello,
It has largely been superseded by p11-kit-trust, which in the NSS case
provides a replacement for libnssckbi.so and gives us consistency across
the entire system regardless of the crypto libraries in use. (This
wasn't in RHEL6; it came in with Fedora 19 so hopefully it's in RHEL7).
FWIW this is also available in RHEL ≥ 6.5, but you have to opt in via
(update-ca-trust enable).
Great. So that should solve Patrik's CA issues without needing to do
anything special. All that remains is to get the smartcards working by
loading p11-kit-proxy.so (or preferably the individual modules) too.
Is that something we could do in the p11-kit-trust implementation of
libnssckbi.so without having to add another hook?
That feels like an pretty icky workaround, but I don’t actually know whether it
would or wouldn’t work. Stef, could the RHEL 6.5 p11-kit{,-trust} be (ab)used
to load a smartcard token into all NSS users (without changing the
application-specific NSS configuration)?
Mirek
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Tue, 2014-12-02 at 12:00 -0500, Miloslav Trmač wrote:
Great. So that should solve Patrik's CA issues without needing to do
anything special. All that remains is to get the smartcards working by
loading p11-kit-proxy.so (or preferably the individual modules) too.
Is that something we could do in the p11-kit-trust implementation of
libnssckbi.so without having to add another hook?
That feels like an pretty icky workaround, but I don’t actually know
whether it would or wouldn’t work. Stef, could the RHEL 6.5
p11-kit{,-trust} be (ab)used to load a smartcard token into all NSS
users (without changing the application-specific NSS configuration)?
Well, the first question to ask would be about doing it upstream.
Whether it can be backported to RHEL is a separate question for product
management. (Individual users can of course do their own thing).
I agree that it's a pretty icky workaround, but then again so is the
current practice of simply *replacing* NSS's own implementation of
libnssckbi.so with our own. But it's a neat trick which happens to work
fairly nicely, and if we can extend it to *also* get the p11-kit
configured modules to load at the same time without having to come up
with further hacks, that would be quite nice.
It also puts us in a good position to deal with the recursion that would
otherwise happen when we attempt to put sql:$HOME/pki/nssdb into the
user's p11-kit configuration. Doing that *and* manually configuring
p11-kit-proxy into the NSS stack doesn't end well at the moment, but it
should hopefully be simple to eliminate the duplicate if we do it this
way.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
Hi again,
Thanks for all the info guys, it certainly answered some of my questions
(and I've also figured out some stuff while digging on my own).
With that being said, this still seems like a *huge* jungle for a
sysadmin, and while the introduction of p11-kit seems promising I'm
still somewhat confused.
So here's a round of new questions,
- There are different ways of loading pkcs11-modules into an application
where nss is one and p11-kit is another. And where p11-kit is a library
that an application can link to, and where nss is a database that an
application opens. And if an application is not linked to libp11-kit, we
can use p11-kit-proxy in our nssdb to get all the features of p11-kit.
Is the above somewhat correct ?
- We put out CA in '/etc/pki/ca-trust/source/anchors/', and import
'/usr/lib64/libnssckbi.so' into our 'sql:/etc/pki/nssdb'. Everything
works as I expect, great! But how is libnssckbi.so relevant to
'/etc/pki/ca-trust/source/anchors/' and/or to p11-kit. I'm having
trouble sorting out and understanding these components. If I remove
libnssckbi.so from 'sql:/etc/pki/nssdb' validation of
self-signed-certificats fails (which must mean that libnssckbi.so adds
my trusted anchors, right ?).
I have now solved our different issues like this,
Have all kinds of applications trust our CA.
Seems to work with just,
1) Put CA in '/etc/pki/ca-trust/source/anchors/'
2) Import 'libnssckbi.so' into 'sql:/etc/pki/nssdb'
3) Run 'update-ca-trust'
Have all kinds of make us of our pkcs11-module if requested.
Seems to work with just (as long as the all kinds of applications is
evolution/ff/chrome),
1) Make sure that '~/.pki/nssdb/pkcs11.txt' contains the lines,
library=/usr/lib64/pkcs11/opensc-pkcs11.so
name=OpenSC PKCS #11 Module
2) Make sure that ~/{.mozilla,.thunderbird}/*/*.default/ contains the
same lines as above.
Step 1 and 2, is made sure by checking this at user-login.
I've decided to remove 'opensc-pkcs11.so' from 'sql://etc/pki/nssdb'
since it's not needed there. Only reason I had it there was because I
thought that 'pam_pkcs11' needed it, but it turns out that 'pam_pkcs11'
will load the specified module from 'pam_pkcs11.conf' directly instead
of through the 'nssdb'.
I've also removed the 'libnsssysinit.so' from 'sql://etc/pki/nssdb' and
everything still seems to work as expected. Do I need it, and if so,
why ?
So, basically we got our CA and smartcard-implementaion working pretty
well.
Maybe it can be done differently and better, but after spending *a lot*
of time on this matter I just feel whatever works.
Edit:
I quickly tried to import libp11-proxy.so in the users nssdb (and
in .mozillas) and it worked as expected. However, since all my
keyrings (?) now are in the slots, evolution (and chrome/ff etc) now
asks me for passwords to all my keyrings (when going into preferences
that is in evolution, or security devices in ff, or manage certificates
in chrome) which are Smartcard, Gnome2 Key Storage, Secret Store.
I do however get a question about unlocking the gnome2-keyring at
login (can't remember if it was the same for the secret store), however
it just seemed oddly designed from a user-perspective. Unlocking the
smartcard when performing the action above I can explain to our ~150
desktop-users, however I just feel it's going to be hassle to try to
explain all the different keyrings that would be available in the
p11-kit-proxy-slots. But maybe I'm missing something here ?
Edit2:
We now have a 'nss.sh' under '/etc/profile.d/' that exports
NSS_DEFAULT_DB_TYPE=sql.
Best regards,
Patrik Martinsson,
Sweden
On Tue, 2014-12-02 at 17:25 +, David Woodhouse wrote:
On Tue, 2014-12-02 at 12:00 -0500, Miloslav Trmač wrote:
Great. So that should solve Patrik's CA issues without needing to do
anything special. All that remains is to get the smartcards working by
loading p11-kit-proxy.so (or preferably the individual modules) too.
Is that something we could do in the p11-kit-trust implementation of
libnssckbi.so without having to add another hook?
That feels like an pretty icky workaround, but I don’t actually know
whether it would or wouldn’t work. Stef, could the RHEL 6.5
p11-kit{,-trust} be (ab)used to load a smartcard token into all NSS
users (without changing the application-specific NSS configuration)?
Well, the first question to ask would be about doing it upstream.
Whether it can be backported to RHEL is a separate question for product
management. (Individual users can of course do their own thing).
I agree that it's a pretty icky workaround, but then again so is the
current practice of simply *replacing* NSS's own implementation of
libnssckbi.so with our own. But it's a neat trick which happens to work
fairly nicely, and if we can extend it to *also* get the p11-kit
configured modules to load at the same time without having to come up
with further hacks, that would be quite nice.
It also puts us in a
Re: libnsssysinit
On Tue, 2014-12-02 at 18:24 +, Martinsson Patrik wrote: So here's a round of new questions, - There are different ways of loading pkcs11-modules into an application where nss is one and p11-kit is another. And where p11-kit is a library that an application can link to, and where nss is a database that an application opens. And if an application is not linked to libp11-kit, we can use p11-kit-proxy in our nssdb to get all the features of p11-kit. Is the above somewhat correct ? Maybe not all the features, but the tokens should be visible and usable. You don't get to reference objects by PKCS#11 URIs and things like that. - We put out CA in '/etc/pki/ca-trust/source/anchors/', and import '/usr/lib64/libnssckbi.so' into our 'sql:/etc/pki/nssdb'. I'm confused about that. Why would you have to explicitly *add* /usr/lib64/libnssckbi.so? That's supposed to be there automatically, already. It contains the default trust roots, in a hard-coded library. Everything works as I expect, great! But how is libnssckbi.so relevant to '/etc/pki/ca-trust/source/anchors/' and/or to p11-kit. What happens is that p11-kit-trust actually *replaces* the NSS version of /usr/lib64/libnssckbi.so with its own, to actually be configurable and consistent with the rest of the system. So /usr/lib64/libnssckbi.so on your system may actually be the p11-kit one, which does use the stuff from /etc/pki/ca-trust. I'm having trouble sorting out and understanding these components. If I remove libnssckbi.so from 'sql:/etc/pki/nssdb' validation of self-signed-certificats fails (which must mean that libnssckbi.so adds my trusted anchors, right ?). That one confuses me too. I suspect it's a bug. Possibly due to the p11-kit 'imposter' version of the module, but I'm not sure. I have now solved our different issues like this, Have all kinds of applications trust our CA. Seems to work with just, 1) Put CA in '/etc/pki/ca-trust/source/anchors/' 2) Import 'libnssckbi.so' into 'sql:/etc/pki/nssdb' 3) Run 'update-ca-trust' Step 2 *really* shouldn't be necessary. I think you should file a Red Hat bug for that with a simple test case, as long as you have run 'update-ca-trust enable' as Miroslav suggests. I've also removed the 'libnsssysinit.so' from 'sql://etc/pki/nssdb' and everything still seems to work as expected. Do I need it, and if so, why ? That will be responsible for loading the read-write database from ~/.pki/nssdb on of of the read-only system database. So if users want to be able to store their *own* trust settings and certificates, you'll want it. So, basically we got our CA and smartcard-implementaion working pretty well. Maybe it can be done differently and better, but after spending *a lot* of time on this matter I just feel whatever works. Yeah, that makes sense. It would be really good to get this to the point where it Just Works and people don't have to jump through so many hoops. Edit: I quickly tried to import libp11-proxy.so in the users nssdb (and in .mozillas) and it worked as expected. However, since all my keyrings (?) now are in the slots, evolution (and chrome/ff etc) now asks me for passwords to all my keyrings (when going into preferences that is in evolution, or security devices in ff, or manage certificates in chrome) which are Smartcard, Gnome2 Key Storage, Secret Store. I do however get a question about unlocking the gnome2-keyring at login (can't remember if it was the same for the secret store), however it just seemed oddly designed from a user-perspective. Unlocking the smartcard when performing the action above I can explain to our ~150 desktop-users, however I just feel it's going to be hassle to try to explain all the different keyrings that would be available in the p11-kit-proxy-slots. But maybe I'm missing something here ? Yeah, not sure why it should be doing that. I don't remember it doing so; will retest with p11-kit-proxy in my NSS stack. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Tue, 2014-12-02 at 18:24 +, Martinsson Patrik wrote: I quickly tried to import libp11-proxy.so in the users nssdb (and in .mozillas) and it worked as expected. However, since all my keyrings (?) now are in the slots, evolution (and chrome/ff etc) now asks me for passwords to all my keyrings (when going into preferences that is in evolution, or security devices in ff, or manage certificates in chrome) which are Smartcard, Gnome2 Key Storage, Secret Store. I do however get a question about unlocking the gnome2-keyring at login (can't remember if it was the same for the secret store), however it just seemed oddly designed from a user-perspective. Unlocking the smartcard when performing the action above I can explain to our ~150 desktop-users, however I just feel it's going to be hassle to try to explain all the different keyrings that would be available in the p11-kit-proxy-slots. But maybe I'm missing something here ? That doesn't happen here on F21, FWIW. Firefox only asks me to log into my p11-kit-provided hardware tokens when I go to a web site which wants a certificate, which is fair enough. And I haven't actually got Evolution to show me any hard evidence that they're loaded at all. I'll have to put a S/MIME certificate onto one of them and see if that works. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On Tue, 2014-12-02 at 19:59 +, David Woodhouse wrote: That doesn't happen here on F21, FWIW. Firefox only asks me to log into my p11-kit-provided hardware tokens when I go to a web site which wants a certificate, which is fair enough. And I haven't actually got Evolution to show me any hard evidence that they're loaded at all. I'll have to put a S/MIME certificate onto one of them and see if that works. There's something weirder going on here. Whenever I start an application (even after disabling the p11-kit replacement for libnssckbi.so) it seems to forcibly *remove* p11-kit-proxy from the modules list. I can get Firefox to use p11-kit-proxy.so but only for one run at a time having manually added it through the GUI. I'm fairly sure that's a recent regression; I tried this once before and it was basically working. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
