** 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-post-2004

-- 
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 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

Reply via email to