> This does raise a question as to why we don't provide a system nssdb. I > think we should. I wonder if libnss or libnss3-tools could ship ca- > certificates hook to provide a system nssdb certificate store.
I don't think it makes much sense at this point as most of the tools that were depending on NSS are leaving it anyways (curl, sssd...) and even Fedora is trying to get rid the usage of libnss completely and only support one crypto backend. So, I was thinking of doing that and it could be a possibility, but wouldn't still be a futurable solution as we'd regress in next LTS, and so we'd end up providing a solution for this LTS (for something that we didn't support so far) that is going to be broken in the next version. And I don't think it's a professional thing to ask our users to setup something and reconfigure it at next mayor update when we can start with the right foot now. > If we are changing backends, and certs were provided for the nss > backend, imho we should automatically convert them and keep them active > for the openssl backend. However unlikely it is that somebody made nss- > based p11_child work. Yeah, as I said isn't hard to do... The only problem I see is that the postinst script for NSS should depend on libnss3-tools (if we don't write us something in C that is shipped with SSSD) in order to read the certs and export them to the OpenSSL chain. As you said, it's quite unlikely, but could happen. > Actually, I don't see sssd at all using TLS connections, does it? It > seems that to perform ldaps connections, it uses libldap from openldap > which in turn uses GnuTLS. And any and all TLS LDAPS options are simply > passed through to the libldap. I had this feeling too, both looking at the code and at the various logs I found around, where I noticed that connection was handled differently, but not being the maximum expert here, I preferred not to talk. So happy you say so. > Inspecting all sssd binary packages I can see that only p11_child is the > only one using libssl and that does not do TLS. Yeah, exactly... It does only certs management basically. > Thus changing nss => openssl backend should be immaterial to what sssd > uses from them. Ok, good to hear. > I don't know how to configure p11_child but I do have > smartcard reader and multiple smartcards so happy to test things =) I wrote a bit of hints in this document, should help: https://hackmd.io/@3v1n0/ubuntu-smartcard-login -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child Status in ca-certificates package in Ubuntu: New Status in sssd package in Ubuntu: Fix Released Status in ca-certificates source package in Focal: New Status in sssd source package in Focal: New Bug description: [ Impact ] SSSD supports in 20.04 two security backends: NSS and OpenSSL (speaking in past tense as upstream dropped NSS support completely). Those two backends are used for various generic crypto features (so they are interchangeable), but also for the management of the PKCS#11 modules for smart cards. In this case, the main problem is that by using NSS it also relies on the presence of a "system NSS" database [1] that is something present in Fedora and RHEL, but not in ubuntu or generic Linux distributions. In order to make SSSD to find a smart card module, we would then need to create a such database that mentions a p11kit proxy that will eventually load the p11-kit module and then add the card CA certificate to the same DB (see more details in [2]). And even in such case... It will not work at login phase. This is making support for Smart-card based authentication in 20.04 quite complicated, and hard to implement in professional environments (see bug #1865226). As per this, recompiling SSSD's p11_child to use OpenSSL (as it already happens starting from 20.10) would be enough to make the this tool (the one in charge for smartcard authentications and certificate matching) to be able to get the smartcard devices from p11-kit allowed modules and to check their certificate using CA certificates in the ubuntu system ca certificate files (or other configured file). One more mayor reason to do this, is also that if we fix 20.04 now to use the "proper" method, people who will configure smartcard access there via SSSD (not easily possible right now) won't be affected by future migrations. [ Proposed Implementations ] 1) Use p11-kit and openssl for p11_child, by changing the build/test system (preferred) https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child 2) Build both versions and package things accordingly (hackish) https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child-v1 [ Test case ] With a smartcard reader available (and with a card in its slot) as reported by: $ p11-kit list-modules launch: $ sudo /usr/libexec/sssd/p11_child --pre -d 10 --debug-fd=2 \ --nssdb=/etc/ssl/certs/ca-certificates.crt The tool should find your card: (2020-11-26 21:34:22:020395): [p11_child[100729]] [do_card] (0x4000): Module List: (2020-11-26 21:34:22:020481): [p11_child[100729]] [do_card] (0x4000): common name: [p11-kit-trust]. (2020-11-26 21:34:22:020497): [p11_child[100729]] [do_card] (0x4000): dll name: [/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so]. (2020-11-26 21:34:22:020569): [p11_child[100729]] [do_card] (0x4000): Description [/etc/ssl/certs/ca-certificates.crt PKCS#11 Kit ] Manufacturer [PKCS#11 Kit ] flags [1] removable [false] token present [true]. (2020-11-26 21:34:22:020611): [p11_child[100729]] [do_card] (0x4000): common name: [opensc-pkcs11]. (2020-11-26 21:34:22:020646): [p11_child[100729]] [do_card] (0x4000): dll name: [/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so]. (2020-11-26 21:34:22:025443): [p11_child[100729]] [do_card] (0x4000): Description [VMware Virtual USB CCID 00 00 VMware ] Manufacturer [VMware ] flags [7] removable [true] token present [true]. (2020-11-26 21:34:22:025725): [p11_child[100729]] [do_card] (0x4000): Found [MARCO TREVISAN (PIN CNS0)] in slot [VMware Virtual USB CCID 00 00][0] of module [1][/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so]. Then the tool might fail if the card certificate is not added to the ca-certificates.crt, but this is outside the scope of the test case. What it matters is that the card is found. [ Regression potential ] While the change may involve quite different code paths when it comes to security features, I think we trust OpenSSL enough to be an acceptable crypto backend for PKCS#11 operations. And behavior should not change (if not improved), also assuming that upstream dropped NSS support completely in latest release, keeping the same functionalities. The only binary that is really affected in its behavior is p11_child. And I'm confident this will break only those setup (if there are any, given that smartcard access is currently not supported by ubuntu) that have been manually configured using an unsupported system NSS db. In the remote case there are such configurations, though, the fix will be as easy as adding the CA certificates to the new PAM cert DB (by default /etc/sssd/pki/sssd_auth_ca_db.pem), while the p11-kit modules will continue to work as before. It's also technically easy to do a postinst script that will just export all the certificates from the old nss db (/etc/pki/nssdb) into the new file, if we want to avoid any unlikely breakage. [1] https://github.com/SSSD/sssd/blob/sssd-2_3_1/src/responder/pam/pamsrv.c#L53 [2] https://hackmd.io/@3v1n0/ubuntu-smartcard-login#NSS-Database-to-be-deprecated-post-2004 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1905790/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
