Bug 1299066 - smartcard login does not prompt for pin when ocsp checking is enabled (default config)
smartcard login does not prompt for pin when ocsp checking is enabled (defaul...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.8
All Linux
high Severity high
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
Aneta Šteflová Petrová
: TestBlocker
Depends On:
Blocks: 1266108 1270027
  Show dependency treegraph
 
Reported: 2016-01-15 16:11 EST by Roshni
Modified: 2016-05-10 16:04 EDT (History)
17 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-10 16:04:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Roshni 2016-01-15 16:11:40 EST
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 03:22:04 EST
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 15:03:50 EST
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 08:54:50 EST
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 07:53:02 EST
(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 11:30:29 EST
[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 12:15:12 EST
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 06:32:07 EST
(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 17:40:17 EST
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 10:20:26 EST
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 11:56:59 EST
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 16:05:01 EST
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 15:04:40 EST
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 16:13:35 EST
Changing component to selinux-policy where it was fixed.
Comment 28 errata-xmlrpc 2016-05-10 16:04:50 EDT
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.