Description of problem: nss not getting the correct ocsp url from the AIA extension of the certificate on a smartcard Version-Release number of selected component (if applicable): nss-3.19.1-9.el6 How reproducible: always Steps to Reproduce: 1. Enroll a smartcard with certificate profiles having ocsp enabled pointing to the corresponding url 2. ipa-client-install --mkhomedir 3. Edit sssd.conf to have [pam] pam_cert_auth = True 4.Create an ipa user and assign the signing cert on the card to the user 5. su to the smartcard user as non-root user Actual results: prompts for user password Expected results: should prompt for smartcard pin Additional info: Seeing the following: [root@dhcp123-129 nssdb]# certutil -V -d . -n "ipasmartcarduser2:signing key for ipasmartcarduser2" -u O Enter Password or Pin for "ipasmartcarduser2": certutil: certificate is invalid: Certificate type not approved for application. su and gdm login prompts for smartcard pin (and login is successful) if ocsp check is disabled in sssd.conf [sssd] certificate_verification = no_ocsp
I think certutil does not do any ocsp validation and '-u O' isn't correct here as well (O stands for 'OCSP status responder' so for the certificate of the OCSP responder itself) For user certificates you should use '-u C' and I would expect that certutil will say that the certificate is valid (because it does not od the OCSP check). There is an additional tool, /usr/lib/nss/unsupported-tools/ocspclnt, which should be able to do OCSP validation. Please try /usr/lib/nss/unsupported-tools/ocspclnt -V "ipasmartcarduser2:signing key for ipasmartcarduser2" -d . Additionally can can set epxort NSS_TRACE_OCSP=true to get extra debug output.
Sumit discovered the following: it is an SELinux issue. Since OCSP works over the network p11_child has to be allowed to open network connections. If 'setsebool allow_ypbind true' smartcard login prompts for pin.
Lukas, can you please advise if we can fix the system policy or handle it in other, better way? Network access is only needed for some of the certificates with OCSP. It depends on how conservative we want to.
(In reply to Roshni from comment #3) > Sumit discovered the following: > > it is an SELinux issue. Since OCSP works over the network p11_child has to > be allowed to open network connections. If 'setsebool allow_ypbind true' > smartcard login prompts for pin. Could you attach raw AVC msgs? It looks like we will need to fix the system policy.
[root@dhcp123-129 ~]# ausearch -ts recent -m AVC ---- time->Mon Feb 1 11:26:56 2016 type=SYSCALL msg=audit(1454344016.597:42): arch=40000003 syscall=5 success=no exit=-13 a0=8b846d0 a1=20002 a2=180 a3=8b846b8 items=0 ppid=3052 pid=3195 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="p11_child" exe="/usr/libexec/sssd/p11_child" subj=unconfined_u:system_r:sssd_t:s0 key=(null) type=AVC msg=audit(1454344016.597:42): avc: denied { read write } for pid=3195 comm="p11_child" name=636F6F6C6B6579706B3131734F6D6E694B657920436172644D616E20333132312030302030302D30 dev=dm-0 ino=654671 scontext=unconfined_u:system_r:sssd_t:s0 tcontext=unconfined_u:object_r:auth_cache_t:s0 tclass=file ---- time->Mon Feb 1 11:26:58 2016 type=SYSCALL msg=audit(1454344018.309:43): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe8adf0 a2=67c4ff4 a3=bfe8b410 items=0 ppid=3052 pid=3195 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="p11_child" exe="/usr/libexec/sssd/p11_child" subj=unconfined_u:system_r:sssd_t:s0 key=(null) type=AVC msg=audit(1454344018.309:43): avc: denied { name_connect } for pid=3195 comm="p11_child" dest=80 scontext=unconfined_u:system_r:sssd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket ---- time->Mon Feb 1 11:26:58 2016 type=SYSCALL msg=audit(1454344018.309:44): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe8adf0 a2=67c4ff4 a3=bfe8b410 items=0 ppid=3052 pid=3195 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="p11_child" exe="/usr/libexec/sssd/p11_child" subj=unconfined_u:system_r:sssd_t:s0 key=(null) type=AVC msg=audit(1454344018.309:44): avc: denied { name_connect } for pid=3195 comm="p11_child" dest=80 scontext=unconfined_u:system_r:sssd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket ---- time->Mon Feb 1 11:26:58 2016 type=SYSCALL msg=audit(1454344018.310:45): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe8adf0 a2=67c4ff4 a3=bfe8b410 items=0 ppid=3052 pid=3195 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="p11_child" exe="/usr/libexec/sssd/p11_child" subj=unconfined_u:system_r:sssd_t:s0 key=(null) type=AVC msg=audit(1454344018.310:45): avc: denied { name_connect } for pid=3195 comm="p11_child" dest=80 scontext=unconfined_u:system_r:sssd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket ---- time->Mon Feb 1 11:26:58 2016 type=SYSCALL msg=audit(1454344018.311:46): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe8adf0 a2=67c4ff4 a3=bfe8b410 items=0 ppid=3052 pid=3195 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="p11_child" exe="/usr/libexec/sssd/p11_child" subj=unconfined_u:system_r:sssd_t:s0 key=(null) type=AVC msg=audit(1454344018.311:46): avc: denied { name_connect } for pid=3195 comm="p11_child" dest=80 scontext=unconfined_u:system_r:sssd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
After upgrading to coolkey-1.1.0-37.el6 seeing the following in enforcing mode: [root@dhcp123-129 ~]# ausearch -ts recent -m AVC ---- time->Mon Feb 1 12:10:08 2016 type=SYSCALL msg=audit(1454346608.643:77): arch=40000003 syscall=5 success=yes exit=12 a0=9ce66d0 a1=20002 a2=180 a3=9ce66b8 items=0 ppid=3778 pid=3897 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="p11_child" exe="/usr/libexec/sssd/p11_child" subj=unconfined_u:system_r:sssd_t:s0 key=(null) type=AVC msg=audit(1454346608.643:77): avc: denied { read write } for pid=3897 comm="p11_child" name=636F6F6C6B6579706B3131734F6D6E694B657920436172644D616E20333132312030302030302D30 dev=dm-0 ino=654671 scontext=unconfined_u:system_r:sssd_t:s0 tcontext=unconfined_u:object_r:auth_cache_t:s0 tclass=file ---- time->Mon Feb 1 12:10:43 2016 type=SYSCALL msg=audit(1454346643.155:81): arch=40000003 syscall=5 success=no exit=-13 a0=95096d0 a1=20002 a2=180 a3=95096b8 items=0 ppid=3778 pid=3904 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="p11_child" exe="/usr/libexec/sssd/p11_child" subj=unconfined_u:system_r:sssd_t:s0 key=(null) type=AVC msg=audit(1454346643.155:81): avc: denied { read write } for pid=3904 comm="p11_child" name=636F6F6C6B6579706B3131734F6D6E694B657920436172644D616E20333132312030302030302D30 dev=dm-0 ino=654671 scontext=unconfined_u:system_r:sssd_t:s0 tcontext=unconfined_u:object_r:auth_cache_t:s0 tclass=file
(In reply to Miroslav Grepl from comment #5) ... > Could you attach raw AVC msgs? It looks like we will need to fix the system > policy. Thanks. We would also welcome your advise regarding Comment 3 and Comment 4, if we want to be conservative and simply decline OCSP checks or more open and allow the network connections.
AVC messages on RHEL 6.8 based on the instructions in https://bugzilla.redhat.com/show_bug.cgi?id=1303709#c4: [root@dhcp123-129 ~]# ausearch -ts recent -m AVC time->Mon Feb 8 17:35:12 2016 type=SYSCALL msg=audit(1454970912.959:15): arch=40000003 syscall=5 success=yes exit=12 a0=8ded6d0 a1=20002 a2=180 a3=8ded6b8 items=0 ppid=1847 pid=3538 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="p11_child" exe="/usr/libexec/sssd/p11_child" subj=system_u:system_r:sssd_t:s0 key=(null) type=AVC msg=audit(1454970912.959:15): avc: denied { read write } for pid=3538 comm="p11_child" name=636F6F6C6B6579706B3131734F6D6E694B657920436172644D616E20333132312030302030302D30 dev=dm-0 ino=654671 scontext=system_u:system_r:sssd_t:s0 tcontext=unconfined_u:object_r:auth_cache_t:s0 tclass=file
Could you please test it with # cat mypol.te policy_module(mypol,1.0) require{ type sssd_t; } auth_rw_cache(sssd_t) corenet_tcp_connect_http_port(sssd_t) and run # make -f /usr/share/selinux/devel/Makefily mypol.pp # semodule -i mypol.pp Thank you,
Need more clarification on this, do I have to try the following in enforcing mode? # setenforce 1 # semanage permissive -a sssd_t and then run the following? (In reply to Miroslav Grepl from comment #11) > Could you please test it with > > > # cat mypol.te > policy_module(mypol,1.0) > > require{ > type sssd_t; > } > > auth_rw_cache(sssd_t) > corenet_tcp_connect_http_port(sssd_t) > > > and run > > # make -f /usr/share/selinux/devel/Makefily mypol.pp > # semodule -i mypol.pp > > Thank you,
The following is what I tried [root@dhcp123-129 ~]# setenforce 1 [root@dhcp123-129 ~]# semanage permissive -a sssd_t [root@dhcp123-129 ~]# semodule -i mypol.pp [root@dhcp123-129 ~]# exit logout [rpattath@dhcp123-129 ~]$ su troy.jones.1402301836 PIN for TROY.JONES.1402301836 for user troy.jones.1402301836 sh-4.1$ exit exit [rpattath@dhcp123-129 ~]$ su - Password: [root@dhcp123-129 ~]# semanage permissive -d sssd_t [root@dhcp123-129 ~]# exit logout [rpattath@dhcp123-129 ~]$ su troy.jones.1402301836 PIN for TROY.JONES.1402301836 for user troy.jones.1402301836 sh-4.1$
I tested the scenario using selinux-policy-3.7.19-288.el6 along with the latest RHEL 6.8 nightly compose builds as of today. Since I had all the workarounds and the selinux module in comment 11 added in the test environment, the following is what I tried setenforce 1 semanage permissive -d sssd_t semodule -r mypol.pp setsebool -P allow_ypbind false After running the above commands, gdm login, su and ssh using the smartcard with the ipa user prompts for smartcard pin and login is successful.
Changing component to selinux-policy where it was fixed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0763.html