Re: [Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support for p11_child
>> Soo... Given we prefer to stay conservative and not change SSSD crypto > > I didn't say that! I know, I'm not saying that you took a decision on that but I was speaking in plural form as I recognize what you say in the sense that indeed there may be cases which we don't think of that we could break. >> backend fully (to be clear, I would have preferred it to follow >> upstream, not to provide a solution that will change in next LTS no >> matter what, and avoid having "frankensteins", but wasn't a strong >> requirement for me) I've been exploring ways to get only the component >> we care (p11_child) to use p11-kit and openssl. > > This is certainly a valuable angle to look at - thanks! > >> Robie, this would be better SRU approach? > > I think you misunderstand me. I'm not saying that your upload *has* to > be narrow. I've not formed an opinion that yet. What I'm saying is that > whatever size of scope you choose, there must be a regression analysis > that covers that scope. I understood this, reason why I thought that, given we have the chance to make it a narrower scope, then I tried to get that done. > But the analysis is still necessary and must not be skipped. Sure, not trying to do that, I'm just saying that I can't over all the cases myself. > I appreciate that sometimes it's harder or riskier to narrow the scope, > so I'm still open to widening the scope - *if* there is an appropriate > justification *and* full regression analysis of that wider scope > provided. Problem is that I'm quite sure we can't cover all the cases in a such complicated piece of software that may be configured in so many ways. Thus the reason I thought narrowing the scope was a better idea. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support for p11_child
On Wed, Dec 02, 2020 at 03:29:43AM -, Marco Trevisan (Treviño) wrote: > Soo... Given we prefer to stay conservative and not change SSSD crypto I didn't say that! > backend fully (to be clear, I would have preferred it to follow > upstream, not to provide a solution that will change in next LTS no > matter what, and avoid having "frankensteins", but wasn't a strong > requirement for me) I've been exploring ways to get only the component > we care (p11_child) to use p11-kit and openssl. This is certainly a valuable angle to look at - thanks! > Robie, this would be better SRU approach? I think you misunderstand me. I'm not saying that your upload *has* to be narrow. I've not formed an opinion that yet. What I'm saying is that whatever size of scope you choose, there must be a regression analysis that covers that scope. If you take a widely scope, then I expect a regression analysis to cover what I feel are the obvious possible implications of that change. By nature of it being wider, the regression analysis can be expected to be more work, of course. Because a wider scope generally correlates with increased regression risk, I'd also expect a justification of why the narrow scope is less desirable. But the analysis is still necessary and must not be skipped. If you take a narrow scope, then that's correlated with lower regression risk, and because a regression analysis would be narrower in scope to match, it might well be less work. I appreciate that sometimes it's harder or riskier to narrow the scope, so I'm still open to widening the scope - *if* there is an appropriate justification *and* full regression analysis of that wider scope provided. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support for p11_child
Soo... Given we prefer to stay conservative and not change SSSD crypto backend fully (to be clear, I would have preferred it to follow upstream, not to provide a solution that will change in next LTS no matter what, and avoid having "frankensteins", but wasn't a strong requirement for me) I've been exploring ways to get only the component we care (p11_child) to use p11-kit and openssl. As per this, I've prepared two possible approaches in two patches (I'd just squash those or pick one in case). The simplest approach [1] was to just compile the NSS version and then only the p11_child using OpenSSL and then manually install to the package... Ensuring that we always pass to it a PEM CA cert file. Works, but will not allow us to test it using upstream tests. So, I've added a further patch that acts mostly on upstream code and removes the usage of libnss ONLY from p11_child and its related operations (smartcard and ssh auth), you can see it better in this patch-queue branch (check the default one to see the debian/* changes): - https://salsa.debian.org/3v1n0-guest/sssd/-/commits/patch-queue/p11-kit-p11_child This works properly and it's tested, you can try the packages at: - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4361.1 Theoretically, it would be even possible to keep support for an NSS p11_child (i.e. provide two binaries, and select which one to use depending on the db defined in configuration file), but as said in the bug description I don't think that such change would actually matter for anyone, as we don't provide a system NSS database. Robie, this would be better SRU approach? [1] https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit- p11_child-v1 ** Summary changed: - Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support for p11_child + Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support for p11_child
** Summary changed: - Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support + Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support for p11_child ** Description changed: [ 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, just recompiling SSSD to use OpenSSL (as it already happens + As per this, recompiling SSSD to use OpenSSL (as it already happens starting from 20.10) would be enough to make the p11_child tool (the one in charge for smartcard authentications) 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. [ Test case ] With a smartcard reader available (and with a card in its slot) 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. And behavior should not change. 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 that even changing this a lot, it 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
Re: [Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
On Tue, Dec 01, 2020 at 03:22:33PM -, Marco Trevisan (Treviño) wrote: > > What if, for example, someone has an LDAP server that only supports > > older TLS, and switching to OpenSSL causes their sssd LDAP TLS client to > > require newer TLS because of our stronger defaults? What I describe > > would result in a regression for that user until they reconfigure > > things. Is this a realistic possibility? > > First, are we sure that such scenario would currently work in current > NSS? I don't know. You tell me! I expect this to be considered and investigated in advance of an SRU. > I can't say whether that's a realistic scenario, we would need metrics, > but I also think that if you're forcing a more secure behavior it's not > to me a regression, it's making people aware that they're misbehaving. > > As we do SRU a browser version that no longer accepts a deprecated > crypto mechanisms, potentially causing an user regression, I don't see a > problem in doing it other tools. I agree that it may be reasonable in principle to bump up default cryptosystem requirements during the lifetime of an LTS on security grounds. However that decision should be made deliberately and carefully as part of a security-driven review into the trade-offs between security enhancement and user regression. In the case of browsers, this review is done by upstreams and distributions generally have no choice in the matter. In the case of such a change being driven by Ubuntu, I'd expect the review to be driven *by the security concern itself*, probably have input from the security team, and for the proposed change to have a specific security-enhancing goal. Swapping out NSS for OpenSSL without analyzing these types changes, and therefore possibly *accidentally* adjusting this type of configuration, does not meet my expectations detailed above and in my opinion is unacceptable. You seem to be claiming that my example would enhance security, albeit in a breaking way, and is thus acceptable. Without analyzing the details, how do you know my example is the reality though? How do you know it isn't regressing security in a breaking way? > It may require an admin action? Yes, but that's acceptable IMHO when the > system in use is known to be not secure. > And IMHO we're responsible for that too, not just accept people to use unsafe > methods by default. > > > I think you're thinking of functional regressions here (ie. introducing > > actual bugs), whereas I'm more bothered about regressing edge case user > > configurations (eg. introducing a change that requires users to change > > their local configurations to avoid a behavioural regression). > > I'm thinking at those too (and especially in my scenario), but given > there's right now no known actual and reported regression (not just in > Ubuntu, but everywhere in the web I've searched for), so while there > might be indeed edge cases until I don't have proofs of them I still > thinking that the proposed change can only cause an improvement. I disagree with your approach here. To land an SRU we are expected to consider what regressions *might* occur, even if we don't specifically have evidence about them. Lack of known and reported regressions does not give us a free pass; in fact that's the exact opposite of documented Ubuntu SRU policy. We don't expect people to be perfect, but we do expect people to have taken some reasonable effort to consider the potential regression impact. I expect the potential areas of regression I've identified to be investigated and to be reported in this bug. I'm not saying they are blockers; I'm saying that I don't know if they should be blockers, and I think we should determine that with a reasonable documented justification, and then proceed accordingly. I don't think it's productive to be spending time arguing about about *whether* investigation of potential regression is unnecessary. > BTW, unrelated to this, but this request mostly is triggered by bug > #1865226, and to support it reliably we need to use open-ssl based > p11_child. If, after having done a proper analysis, we decide that fixing that bug is on balance worth the risk of regression as the least-worst option, then we might decide to go ahead on that basis. We might even accept some known use case regressions requiring users to reconfigure. But without actually doing the investigation we aren't in a position to be able to weigh it up. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
> What if, for example, someone has an LDAP server that only supports > older TLS, and switching to OpenSSL causes their sssd LDAP TLS client to > require newer TLS because of our stronger defaults? What I describe > would result in a regression for that user until they reconfigure > things. Is this a realistic possibility? First, are we sure that such scenario would currently work in current NSS? I can't say whether that's a realistic scenario, we would need metrics, but I also think that if you're forcing a more secure behavior it's not to me a regression, it's making people aware that they're misbehaving. As we do SRU a browser version that no longer accepts a deprecated crypto mechanisms, potentially causing an user regression, I don't see a problem in doing it other tools. It may require an admin action? Yes, but that's acceptable IMHO when the system in use is known to be not secure. And IMHO we're responsible for that too, not just accept people to use unsafe methods by default. > I think you're thinking of functional regressions here (ie. introducing > actual bugs), whereas I'm more bothered about regressing edge case user > configurations (eg. introducing a change that requires users to change > their local configurations to avoid a behavioural regression). I'm thinking at those too (and especially in my scenario), but given there's right now no known actual and reported regression (not just in Ubuntu, but everywhere in the web I've searched for), so while there might be indeed edge cases until I don't have proofs of them I still thinking that the proposed change can only cause an improvement. -- BTW, unrelated to this, but this request mostly is triggered by bug #1865226, and to support it reliably we need to use open-ssl based p11_child. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
** Description changed: [ Impact ] - SSSD supports in 20.04 two security backends: NSS and OpenSSL. - (speaking in past tense as upstream dropped NSS support completely) + 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. + quite complicated, and hard to implement in professional environments + (see bug #1865226). As per this, just recompiling SSSD to use OpenSSL (as it already happens starting from 20.10) would be enough to make the p11_child tool (the one in charge for smartcard authentications) 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. [ Test case ] With a smartcard reader available (and with a card in its slot) 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. And behavior should not change. 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 that even changing this a lot, it 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 -- You received
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
** Tags added: rls-ff-incoming -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
On Tue, Dec 01, 2020 at 03:33:45AM -, Marco Trevisan (Treviño) wrote: > Probably not enough to compare, but from what I see in these matrices > [4], there's basically nothing that NSS supports and OpenSSL doesn't > (while it's true the other way around). OK, but what about build configuration and default enabled cryptosuites and suchlike? For example we've "locked down" OpenSSL's default configuration to no longer support some older cryptosuites. Will swapping NSS for OpenSSL cause user configurations to narrow the set of cryptosuites that are enabled? What if, for example, someone has an LDAP server that only supports older TLS, and switching to OpenSSL causes their sssd LDAP TLS client to require newer TLS because of our stronger defaults? What I describe would result in a regression for that user until they reconfigure things. Is this a realistic possibility? > Not to mention that we already switched to an OpenSSL-based version of > SSSD in 21.10, and even if its user base can't be compared to 20.04, so > far I didn't read about related issues [5]. I think you're thinking of functional regressions here (ie. introducing actual bugs), whereas I'm more bothered about regressing edge case user configurations (eg. introducing a change that requires users to change their local configurations to avoid a behavioural regression). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
> Are you sure about this? TLS has a wide variety of protocol options and the > supported vs. > "available" cryptosystem matrix is complex. Won't these all change if the > underlying > implementation changes? Well, I focused mostly in the PKCS#11 changes, but for all its internal crypto operations SSSD had for some long time now [1] started supporting OpenSSL, replaced as default [2] and finally dropped [3] NSS at all and the two crypto backends have been used as feature-parity alternatives. Probably not enough to compare, but from what I see in these matrices [4], there's basically nothing that NSS supports and OpenSSL doesn't (while it's true the other way around). Not to mention that we already switched to an OpenSSL-based version of SSSD in 21.10, and even if its user base can't be compared to 20.04, so far I didn't read about related issues [5]. That said, if the SRU team would feel more confident in only having the p11_child to be built with OpenSSL, it should be technically possible, of course not as easy (and probably safer and more future-proof) as switching completely. [1] https://github.com/SSSD/sssd/issues/4521 [2] https://github.com/SSSD/sssd/pull/1042 [3] https://github.com/SSSD/sssd/issues/1041 [4] https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations [5] https://github.com/SSSD/sssd/issues?q=is%3Aissue+openssl+ ** Bug watch added: github.com/SSSD/sssd/issues #4521 https://github.com/SSSD/sssd/issues/4521 ** Bug watch added: github.com/SSSD/sssd/issues #1041 https://github.com/SSSD/sssd/issues/1041 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
** Description changed: [ Impact ] - SSSD supports two security backends: NSS and OpenSSL. + 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. As per this, just recompiling SSSD to use OpenSSL (as it already happens starting from 20.10) would be enough to make the p11_child tool (the one in charge for smartcard authentications) 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. [ Test case ] With a smartcard reader available (and with a card in its slot) 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. And behavior should not change. + 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. And behavior should not change. + 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 that even changing this a lot, it 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-po
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
** Changed in: sssd (Ubuntu Focal) Assignee: (unassigned) => Sergio Durigan Junior (sergiodj) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
> 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. And behavior should not change. Are you sure about this? TLS has a wide variety of protocol options and the supported vs. "available" cryptosystem matrix is complex. Won't these all change if the underlying implementation changes? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support
** Tags added: server-next -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Recompile SSSD in 20.04 using OpenSSL (instead of NSS) support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
