RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1299066 - smartcard login does not prompt for pin when ocsp checking is enabled (default config)
Summary: smartcard login does not prompt for pin when ocsp checking is enabled (defaul...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.8
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
Aneta Šteflová Petrová
URL:
Whiteboard:
Depends On:
Blocks: 1266108 1270027
TreeView+ depends on / blocked
 
Reported: 2016-01-15 21:11 UTC by Roshni
Modified: 2016-05-10 20:04 UTC (History)
17 users (show)

Fixed In Version: selinux-policy-3.7.19-288.el6
Doc Type: Bug Fix
Doc Text:
The user is prompted for smart card PIN as expected Due to insufficient SELinux policy rules, the `ppl_child` process, running in the `sssd_t` SELinux domain, was unable to manage the authentication cache and connect to Apache ports. Consequently, the system did not prompt the user for smart card PIN. The SELinux policy rules, provided by the _selinux-policy_ package, have been updated to allow this functionality. As a result, the user is prompted for smart card PIN as expected in the described situation.
Clone Of:
Environment:
Last Closed: 2016-05-10 20:04:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0763 0 normal SHIPPED_LIVE selinux-policy bug fix update 2016-05-10 22:33:46 UTC

Description Roshni 2016-01-15 21:11:40 UTC 
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
Comment 2 Sumit Bose 2016-01-18 08:22:04 UTC 
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.
Comment 3 Roshni 2016-01-18 20:03:50 UTC 
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.
Comment 4 Martin Kosek 2016-01-19 13:54:50 UTC 
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.
Comment 5 Miroslav Grepl 2016-01-29 12:53:02 UTC 
(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.
Comment 6 Roshni 2016-02-01 16:30:29 UTC 
[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
Comment 7 Roshni 2016-02-01 17:15:12 UTC 
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
Comment 9 Martin Kosek 2016-02-02 11:32:07 UTC 
(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.
Comment 10 Roshni 2016-02-08 22:40:17 UTC 
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
Comment 11 Miroslav Grepl 2016-02-11 15:20:26 UTC 
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,
Comment 12 Roshni 2016-02-11 16:56:59 UTC 
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,
Comment 13 Roshni 2016-02-11 21:05:01 UTC 
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$
Comment 14 Roshni 2016-02-12 20:04:40 UTC 
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.
Comment 15 Petr Vobornik 2016-02-15 21:13:35 UTC 
Changing component to selinux-policy where it was fixed.
Comment 28 errata-xmlrpc 2016-05-10 20:04:50 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.