| 2020-11-26 20:59:28 |
Marco Trevisan (Treviño) |
bug |
|
|
added bug |
| 2020-11-26 20:59:45 |
Marco Trevisan (Treviño) |
nominated for series |
|
Ubuntu Focal |
|
| 2020-11-26 20:59:45 |
Marco Trevisan (Treviño) |
bug task added |
|
sssd (Ubuntu Focal) |
|
| 2020-11-26 20:59:50 |
Marco Trevisan (Treviño) |
sssd (Ubuntu Focal): importance |
Undecided |
High |
|
| 2020-11-26 21:03:55 |
Marco Trevisan (Treviño) |
description |
[ Impact ]
SSSD supports two security backends: NSS and OpenSSL.
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.
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.
[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 |
[ Impact ]
SSSD supports two security backends: NSS and OpenSSL.
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.
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 into 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 |
|
| 2020-11-26 21:04:19 |
Marco Trevisan (Treviño) |
description |
[ Impact ]
SSSD supports two security backends: NSS and OpenSSL.
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.
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 into 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 |
[ Impact ]
SSSD supports two security backends: NSS and OpenSSL.
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.
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 |
|
| 2020-11-27 11:16:27 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2020-11-27 11:16:33 |
Christian Ehrhardt |
tags |
|
server-next |
|
| 2020-11-27 21:21:02 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2020-11-28 01:14:44 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Sergio Durigan Junior |
| 2020-11-28 01:14:56 |
Sergio Durigan Junior |
sssd (Ubuntu Focal): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2020-12-01 02:57:07 |
Marco Trevisan (Treviño) |
description |
[ Impact ]
SSSD supports two security backends: NSS and OpenSSL.
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.
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 |
[ 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.
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 |
|
| 2020-12-01 03:33:45 |
Marco Trevisan (Treviño) |
bug watch added |
|
https://github.com/SSSD/sssd/issues/4521 |
|
| 2020-12-01 03:33:45 |
Marco Trevisan (Treviño) |
bug watch added |
|
https://github.com/SSSD/sssd/issues/1041 |
|
| 2020-12-01 14:37:00 |
Marco Trevisan (Treviño) |
tags |
server-next |
rls-ff-incoming server-next |
|
| 2020-12-01 14:46:27 |
Marco Trevisan (Treviño) |
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.
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 |
[ 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 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 |
|
| 2020-12-01 20:54:03 |
Marco Trevisan (Treviño) |
summary |
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 |
|
| 2020-12-01 20:55:13 |
Marco Trevisan (Treviño) |
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, 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 |
[ 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 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 |
|
| 2020-12-02 03:34:13 |
Marco Trevisan (Treviño) |
summary |
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 |
|
| 2020-12-02 03:41:31 |
Marco Trevisan (Treviño) |
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 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 |
[ 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) 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 |
|
| 2020-12-02 03:43:12 |
Marco Trevisan (Treviño) |
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) 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 |
[ 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 |
|
| 2020-12-02 03:48:40 |
Marco Trevisan (Treviño) |
tags |
rls-ff-incoming server-next |
patch rls-ff-incoming server-next |
|
| 2020-12-03 12:26:35 |
Dimitri John Ledkov |
bug task added |
|
ca-certificates (Ubuntu) |
|
| 2020-12-03 16:25:01 |
Marco Trevisan (Treviño) |
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 |
[ 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
3) Recompile SSSD completely to use libcrypto as backend
[ 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. Behavior should not change, also assuming that upstream dropped NSS support completely in latest release [3], keeping the same functionalities.
As per a further review of this by xnox [4], we can safely assume that SSSD does not use libcrypto for operations where its behavior should differ from NSS. As it's needed only for certificates handling.
The only binary that is really affected in its behavior is p11_child (as per p11-kit usage instead of NSS for getting pkcs#11 modules).
So this change 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.
While we're providing a post-install script that migrates the possibly configured NSS CA certificates, there could be still possible regressions:
1) certificates not to be handled (referenced) in the same way, for example in the SSSD
certmap: the mapping between users and their certificate could change, not making an
user being able to access to the system anymore, not being correctly be correctly
associated to a certificate.
-> This can be fixed by adapting the [certmap/*/*] options in sssd.conf
2) custom p11-kit modules configured as allowed in the NSS database and not recognized by
p11-kit, won't be accepted anymore, so again login won't work as p11_child won't find a
module.
-> Modules can be added creating .module files in /usr/share/p11-kit/modules/
So 1) can be the mayor concern here, even though I assume the few custom installations that there might be around can be adapted to this, in case this proves to be an important regression we can go back to use NSS as backend for libsss_certs, but still using p11-kit + openssl for p11_child.
Instead 2) can be a lower problem to handle, in case of a regression we can think of listing all the modules added to the NSS database, and if any, generate a module file for it, but I'd prefer to avoid this unless needed as we should trust them.
Said this, given the fact that there are probably not known implementations using this system for authentication in Ubuntu, I'm confident that we can accept those two regressions as they are, but being prepared to handle them (as described) if they end up in being real concerns.
[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
[3] https://github.com/SSSD/sssd/issues/1041
[4] https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/comments/10 |
|
| 2020-12-16 04:11:28 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~3v1n0/ubuntu/+source/sssd/+git/sssd/+merge/395410 |
|
| 2020-12-16 04:35:18 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~3v1n0/ubuntu/+source/sssd/+git/sssd/+merge/395411 |
|
| 2020-12-16 05:02:26 |
Marco Trevisan (Treviño) |
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
3) Recompile SSSD completely to use libcrypto as backend
[ 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. Behavior should not change, also assuming that upstream dropped NSS support completely in latest release [3], keeping the same functionalities.
As per a further review of this by xnox [4], we can safely assume that SSSD does not use libcrypto for operations where its behavior should differ from NSS. As it's needed only for certificates handling.
The only binary that is really affected in its behavior is p11_child (as per p11-kit usage instead of NSS for getting pkcs#11 modules).
So this change 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.
While we're providing a post-install script that migrates the possibly configured NSS CA certificates, there could be still possible regressions:
1) certificates not to be handled (referenced) in the same way, for example in the SSSD
certmap: the mapping between users and their certificate could change, not making an
user being able to access to the system anymore, not being correctly be correctly
associated to a certificate.
-> This can be fixed by adapting the [certmap/*/*] options in sssd.conf
2) custom p11-kit modules configured as allowed in the NSS database and not recognized by
p11-kit, won't be accepted anymore, so again login won't work as p11_child won't find a
module.
-> Modules can be added creating .module files in /usr/share/p11-kit/modules/
So 1) can be the mayor concern here, even though I assume the few custom installations that there might be around can be adapted to this, in case this proves to be an important regression we can go back to use NSS as backend for libsss_certs, but still using p11-kit + openssl for p11_child.
Instead 2) can be a lower problem to handle, in case of a regression we can think of listing all the modules added to the NSS database, and if any, generate a module file for it, but I'd prefer to avoid this unless needed as we should trust them.
Said this, given the fact that there are probably not known implementations using this system for authentication in Ubuntu, I'm confident that we can accept those two regressions as they are, but being prepared to handle them (as described) if they end up in being real concerns.
[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
[3] https://github.com/SSSD/sssd/issues/1041
[4] https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/comments/10 |
[ 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
3) Recompile SSSD completely to use libcrypto as backend
[ 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:
1) If you previously configured SSSD match rules and/or CA certificates:
- You should still get your certificate public key printed as output
- Configured login with smartcard should continue working
2) If SSSD was not configured to do smartcard authentication:
- p11_child may fail if the card certificate was not previously added to
the trusted DB, but this is outside of this 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. Behavior should not change, also assuming that upstream dropped NSS support completely in latest release [3], keeping the same functionalities.
As per a further review of this by xnox [4], we can safely assume that SSSD does not use libcrypto for operations where its behavior should differ from NSS. As it's needed only for certificates handling.
The only binary that is really affected in its behavior is p11_child (as per p11-kit usage instead of NSS for getting pkcs#11 modules).
So this change 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.
While we're providing a post-install script that migrates the possibly configured NSS CA certificates, there could be still possible regressions:
1) certificates not to be handled (referenced) in the same way, for example in the SSSD
certmap: the mapping between users and their certificate could change, not making an
user being able to access to the system anymore, not being correctly be correctly
associated to a certificate.
-> This can be fixed by adapting the [certmap/*/*] options in sssd.conf
2) custom p11-kit modules configured as allowed in the NSS database and not recognized by
p11-kit, won't be accepted anymore, so again login won't work as p11_child won't find a
module.
-> Modules can be added creating .module files in /usr/share/p11-kit/modules/
So 1) can be the mayor concern here, even though I assume the few custom installations that there might be around can be adapted to this, in case this proves to be an important regression we can go back to use NSS as backend for libsss_certs, but still using p11-kit + openssl for p11_child.
Instead 2) can be a lower problem to handle, in case of a regression we can think of listing all the modules added to the NSS database, and if any, generate a module file for it, but I'd prefer to avoid this unless needed as we should trust them.
Said this, given the fact that there are probably not known implementations using this system for authentication in Ubuntu, I'm confident that we can accept those two regressions as they are, but being prepared to handle them (as described) if they end up in being real concerns.
[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
[3] https://github.com/SSSD/sssd/issues/1041
[4] https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/comments/10 |
|
| 2020-12-16 05:03:32 |
Marco Trevisan (Treviño) |
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
3) Recompile SSSD completely to use libcrypto as backend
[ 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:
1) If you previously configured SSSD match rules and/or CA certificates:
- You should still get your certificate public key printed as output
- Configured login with smartcard should continue working
2) If SSSD was not configured to do smartcard authentication:
- p11_child may fail if the card certificate was not previously added to
the trusted DB, but this is outside of this 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. Behavior should not change, also assuming that upstream dropped NSS support completely in latest release [3], keeping the same functionalities.
As per a further review of this by xnox [4], we can safely assume that SSSD does not use libcrypto for operations where its behavior should differ from NSS. As it's needed only for certificates handling.
The only binary that is really affected in its behavior is p11_child (as per p11-kit usage instead of NSS for getting pkcs#11 modules).
So this change 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.
While we're providing a post-install script that migrates the possibly configured NSS CA certificates, there could be still possible regressions:
1) certificates not to be handled (referenced) in the same way, for example in the SSSD
certmap: the mapping between users and their certificate could change, not making an
user being able to access to the system anymore, not being correctly be correctly
associated to a certificate.
-> This can be fixed by adapting the [certmap/*/*] options in sssd.conf
2) custom p11-kit modules configured as allowed in the NSS database and not recognized by
p11-kit, won't be accepted anymore, so again login won't work as p11_child won't find a
module.
-> Modules can be added creating .module files in /usr/share/p11-kit/modules/
So 1) can be the mayor concern here, even though I assume the few custom installations that there might be around can be adapted to this, in case this proves to be an important regression we can go back to use NSS as backend for libsss_certs, but still using p11-kit + openssl for p11_child.
Instead 2) can be a lower problem to handle, in case of a regression we can think of listing all the modules added to the NSS database, and if any, generate a module file for it, but I'd prefer to avoid this unless needed as we should trust them.
Said this, given the fact that there are probably not known implementations using this system for authentication in Ubuntu, I'm confident that we can accept those two regressions as they are, but being prepared to handle them (as described) if they end up in being real concerns.
[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
[3] https://github.com/SSSD/sssd/issues/1041
[4] https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/comments/10 |
[ 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
3) Recompile SSSD completely to use libcrypto as backend
The option 3) has been finally choosen, but we also require migration scripts on upgrade.
[ 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:
1) If you previously configured SSSD match rules and/or CA certificates:
- You should still get your certificate public key printed as output
- Configured login with smartcard should continue working
2) If SSSD was not configured to do smartcard authentication:
- p11_child may fail if the card certificate was not previously added to
the trusted DB, but this is outside of this 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. Behavior should not change, also assuming that upstream dropped NSS support completely in latest release [3], keeping the same functionalities.
As per a further review of this by xnox [4], we can safely assume that SSSD does not use libcrypto for operations where its behavior should differ from NSS. As it's needed only for certificates handling.
The only binary that is really affected in its behavior is p11_child (as per p11-kit usage instead of NSS for getting pkcs#11 modules).
So this change 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.
While we're providing a post-install script that migrates the possibly configured NSS CA certificates, there could be still possible regressions:
1) certificates not to be handled (referenced) in the same way, for example in the SSSD
certmap: the mapping between users and their certificate could change, not making an
user being able to access to the system anymore, not being correctly be correctly
associated to a certificate.
-> This can be fixed by adapting the [certmap/*/*] options in sssd.conf
2) custom p11-kit modules configured as allowed in the NSS database and not recognized by
p11-kit, won't be accepted anymore, so again login won't work as p11_child won't find a
module.
-> Modules can be added creating .module files in /usr/share/p11-kit/modules/
So 1) can be the mayor concern here, even though I assume the few custom installations that there might be around can be adapted to this, in case this proves to be an important regression we can go back to use NSS as backend for libsss_certs, but still using p11-kit + openssl for p11_child.
Instead 2) can be a lower problem to handle, in case of a regression we can think of listing all the modules added to the NSS database, and if any, generate a module file for it, but I'd prefer to avoid this unless needed as we should trust them.
Said this, given the fact that there are probably not known implementations using this system for authentication in Ubuntu, I'm confident that we can accept those two regressions as they are, but being prepared to handle them (as described) if they end up in being real concerns.
[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
[3] https://github.com/SSSD/sssd/issues/1041
[4] https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1905790/comments/10 |
|
| 2021-01-12 21:48:11 |
Sergio Durigan Junior |
sssd (Ubuntu Focal): assignee |
Sergio Durigan Junior (sergiodj) |
Marco Trevisan (Treviño) (3v1n0) |
|
| 2021-02-19 17:07:34 |
Robie Basak |
sssd (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2021-02-19 17:07:37 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-02-19 17:07:39 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2021-02-19 17:07:43 |
Robie Basak |
tags |
patch rls-ff-incoming server-next |
patch rls-ff-incoming server-next verification-needed verification-needed-focal |
|
| 2021-02-27 14:32:33 |
Valters Jansons |
tags |
patch rls-ff-incoming server-next verification-needed verification-needed-focal |
patch rls-ff-incoming server-next verification-done verification-done-focal |
|
| 2021-02-28 11:48:38 |
Mathew Hodson |
bug |
|
|
added subscriber Mathew Hodson |
| 2021-03-01 10:50:33 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-03-01 10:50:32 |
Launchpad Janitor |
sssd (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-03-02 03:01:29 |
Mathew Hodson |
removed subscriber Mathew Hodson |
|
|
|
| 2021-03-02 03:01:34 |
Mathew Hodson |
bug task deleted |
ca-certificates (Ubuntu Focal) |
|
|
| 2021-03-02 03:01:39 |
Mathew Hodson |
bug task deleted |
ca-certificates (Ubuntu) |
|
|
| 2021-03-02 03:06:33 |
Mathew Hodson |
bug watch removed |
https://github.com/SSSD/sssd/issues/1041 |
|
|
| 2021-04-06 16:14:55 |
David Coronel |
bug |
|
|
added subscriber David Coronel |
