Re: [Bug 1919563] updated sssd with smart cards now brick systems without full cert chain
Marco, Great! This should be easy for me to test, and I’d be happy to do so. I may be able to do a regression test to make sure the automated NSSDB -> openssl upgrade works as well. This would mean however that the upgrade would need to drop the appropriate sssd.conf.d to configure the partial_chain config option on upgrade. I assume partial_chain will work even if the full chain is present? Karl > On Mar 28, 2021, at 4:15 PM, Marco Trevisan (Treviño) > <1919...@bugs.launchpad.net> wrote: > > So, I've done some work on SSSD upstream to make this to happen: > https://github.com/SSSD/sssd/pull/5558 > > With that we'll just be able to set on upgraders the option > `certification_verification = partial_chain`, and this will just make > the SSSD's PEM ring to work as the NSS db used to work: and so verify a > certificate if its only its issuer is in the SSSD's CA certificates DB. > > This comes with unit tests covering the case with generated > certificates, not sure if I can personally test this with real hardware > (for SRU purposes) though... We may still need to simulate it. > > At the end, it's just as doing: > openssl verify -partial_chain -CAfile intermediate_CA.pem > intermediate_CA_issued_cert.pem > > Karl, will this be enough for you? > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1919563 > > Title: > updated sssd with smart cards now brick systems without full cert > chain > > Status in sssd package in Ubuntu: > New > > Bug description: > With the latest sssd release supporting OpenSSL PKI authentication for > Ubuntu 20.04, the behavior between nssdb and OpenSSL has adversely > affected many systems which are configured for PKI only > authentication. > > The NSSDB implementation of sssd/p11_child ONLY requires the issuing > certificate to be populated to the nssdb and marked as trusted. While > this may be considered a poorly configured system, it is still > technically valid. > > The OpenSSL implementation of the sssd/p11_child requires the FULL > cert chain to the root cert (which is then also trusted by the system > root chain) in order to allow a certificate to authenticate. > > By upgrading to the latest packages, the conversion process from nssdb > to the OpenSSL pam file fails to check the chain of trust, thereby > creating a denial of service for some systems configured to require > smart card/PKI authentication in the pam stack via pam_sss and > require_cert_auth flag. > > Note that this is a popular configuration due to many organizations > are required to follow NIST 800-171 (and other) security derived > policy. Often policy requires PKI based authentication to be enforced > and all other authentication methods disabled. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1919563/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1919563 Title: updated sssd with smart cards now brick systems without full cert chain To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1919563/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1919563] updated sssd with smart cards now brick systems without full cert chain
> On Mar 17, 2021, at 10:01 PM, Marco Trevisan (Treviño) > <1919...@bugs.launchpad.net> wrote: > > So, if I didn't get it wrong, if we'd just use /etc/ssl/certs/ca- > certificates.crt as the SSSD pam certificate in such case would work? While this would technically work, it would be really bad news. This would allow anyone with any user cert issued by a CA in the system wide cert store (by any CA in the world) to be trusted and pass authorization checks by p11_child. (Albeit, some directory attributes would have to line up, depending on your match rules) You only want the full chain of the issuing, intermediate and root CA(s) that are authorized to issue certs to users. Really, going to OpenSSL is a bit of a downgrade. Nssdb, allows one to flag which certs you want to trust, and which certs you don't. There’s no way that I’m aware of to flag a cert in the /etc/sssd/pki/sssd_auth_ca_db.pem to say I trust this cert, but not this other cert. Perhaps the right fix would be that p11_child is updated upstream to use the system cert store to complete chain of trust, and only the authorized issuing CAs should be put in the /etc/sssd/pki/sssd_auth_ca_db.pem file. Perhaps Summit would be willing to add this config option, for which could be set to default to the system store in Ubuntu in the Ubuntu packages. This still assumes a user has properly setup the system store to trust corporate root CAs (and intermediate, since there’s no way to differentiate between trusted root vs untrusted supporting certs in the system store in Ubuntu) > I mean having this in /etc/sssd/sssd.conf > > [pam] > pam_cert_db_path = /etc/ssl/certs/ca-certificates.crt > > And then what was into /etc/sssd/pki/sssd_auth_ca_db.pem to be added to > .crt's under /usr/local/share/ca-certificates/sssd_auth_ca_db/ and > eventually calling update-ca-certificates maybe? > > We could even do the other way around probably, by adding an hook to > /etc/ca-certificates/update.d/ so that we ensure that /etc/ssl/certs/ca- > certificates.crt is always in sync with the system ring? > > > As Robie said, we could revert this change but this would not be ideal for > various reasons IMHO: > 1. As you said this is going to be used more and more, and so we'll have to > end up to keep supporting >a growing number of systems with an outdated method that is going to be > dropped in future >(i.e. better to do it now that its usage is limited than having to do it > in future when the audience > is bigger) > 2. We would like to have a single documented method to have smartcard auth in > ubuntu using SSSD that can >be validated from 20.04 onward and that keep working in future LTSs (and > for sure next LTS will have to drop >NSS anyways, so it's just about delaying a problem making it bigger). Agreed. We just need something to prevent a user from bricking a system by just applying updates from upstream. This is kind of a high priority issue, given folks I’m sure are upgrading daily. By now this issue is starting to creep into offline synced repos. Karl -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1919563 Title: updated sssd with smart cards now brick systems without full cert chain To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1919563/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
