Bug 1549684
| Summary: | [Regression] KRB5_BAD_ENCTYPE in gp_decrypt_buffer when keytab first permitted entry is not ENCTYPE_AES256_CTS_HMAC_SHA1_96 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | miguelangel.js | ||||
| Component: | gssproxy | Assignee: | Robbie Harwood <rharwood> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Ganna Kaihorodova <gkaihoro> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.3 | CC: | abokovoy, fs-qe, gdeschner, gkaihoro, ipa-qe, miguelangel.js, myusuf, ndehadra, nsoman, rharwood, ssorce, yoyang | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | gssproxy-0.7.0-19.el7 | Doc Type: | No Doc Update | ||||
| Doc Text: |
undefined
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-10-30 08:07:58 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1550132 | ||||||
| Attachments: |
|
||||||
Patch was close. I opened this pull request with a complete patch: https://pagure.io/gssproxy/pull-request/226 Fixed in Fedora 28+. QA notes:
To see the failure, you'll need a service configured in gssproxy with a keytab. That keytab needs an algorithm other than AES256_CTS_HMAC_SHA1_96 as the first entry - it's easiest if it's the only one.
Then, attempt an init_sec_context or an accept_sec_context against the keytab. (i.e., start an authentication attempt using the keytab; more on that below.) It should fail somewhat mysteriously, and have something like the following show up in the journal for gssproxy:
Feb 27 15:21:32 kclient gssproxy[20052]: GSSX_RES_INIT_SEC_CONTEXT( status: { 851968 <None> 2 "Unspecified GSS failure. Minor code may provide more information" "" [ ] } context_handle: <Null> output_token: <Null> )
The key is the '2', which is KRB5_BAD_ENCTYPE.
In terms of services, anything will work, though some will be easier to set up than others. The original report uses NFS; I've some infrastructure for setting up NFS environments, but they're very complex (and I've only done it for Fedora so far). Simpler would be a mod_auth_gssapi setup, for which we've some documentation here: https://pagure.io/gssproxy/blob/master/f/docs/Apache.md . It can also be done using python-gssapi, if you've used that - it should only be a few lines.
Version:
ipa-server-4.6.4-6.el7.x86_64
gssproxy-0.7.0-21.el7.x86_64
Verified the bug on the basis of following observations:
Step1: Setup IPA-MASTER and configure as below
-----------------------------------------------
[root@auto-hv-01-guest06]# cd /etc/httpd/conf.d/
[root@auto-hv-01-guest06 conf.d]# echo OK > /var/www/html/private
[root@auto-hv-01-guest06 conf.d]# ls -l
total 48
-rw-r--r--. 1 root root 2926 Jun 22 01:19 autoindex.conf
-rw-r--r--. 1 root root 6469 Aug 21 09:00 ipa.conf
lrwxrwxrwx. 1 root root 36 Aug 21 09:00 ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf
-rw-r--r--. 1 root root 2666 Aug 21 08:59 ipa-pki-proxy.conf
-rw-r--r--. 1 root root 1056 Aug 21 09:00 ipa-rewrite.conf
-rw-r--r--. 1 root root 372 Apr 6 2017 lookup_identity.conf
-rw-r--r--. 1 root root 8479 Aug 21 09:00 nss.conf
-rw-r--r--. 1 root root 366 Jun 22 01:19 README
-rw-r--r--. 1 root root 1252 Jun 22 01:17 userdir.conf
-rw-r--r--. 1 root root 516 Jun 22 01:17 welcome.conf
[root@auto-hv-01-guest06 conf.d]# vim ipa.conf
#### Add following to ipa.conf:
-------------
<Location /private>
AuthType GSSAPI
AuthName "GSSAPI Login"
Require valid-user
</Location>
-------------
[root@auto-hv-01-guest06 conf.d]# hostname
auto-hv-01-guest06.testrelm.test
[root@auto-hv-01-guest06 conf.d]# vi /etc/systemd/system/httpd.service
#### Create httpd.service file and add following details to it
-------------
.include /lib/systemd/system/httpd.service
[Service]
Environment=GSS_USE_PROXY=1
-------------
[root@auto-hv-01-guest06 conf.d]# systemctl daemon-reload
[root@auto-hv-01-guest06 conf.d]# systemctl restart httpd.service
[root@auto-hv-01-guest06 conf.d]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /etc/systemd/system/httpd.service.
Step2: Setup IPA-CLIENT and configure as below
-----------------------------------------------
[root@cloud-qe-04 ~]# ipa-client-install
WARNING: ntpd time&date synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd
Discovery was successful!
Client hostname: cloud-qe-04.testrelm.test
Realm: TESTRELM.TEST
DNS Domain: testrelm.test
IPA Server: auto-hv-01-guest06.testrelm.test
BaseDN: dc=testrelm,dc=test
Continue to configure the system with these values? [no]: yes
Skipping synchronizing time with NTP server.
User authorized to enroll computers: admin
Password for admin:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=TESTRELM.TEST
Issuer: CN=Certificate Authority,O=TESTRELM.TEST
Valid From: 2018-08-21 12:57:36
Valid Until: 2038-08-21 12:57:36
Enrolled in IPA realm TESTRELM.TEST
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm TESTRELM.TEST
trying https://auto-hv-01-guest06.testrelm.test/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://auto-hv-01-guest06.testrelm.test/ipa/json'
trying https://auto-hv-01-guest06.testrelm.test/ipa/session/json
[try 1]: Forwarding 'ping' to json server 'https://auto-hv-01-guest06.testrelm.test/ipa/session/json'
[try 1]: Forwarding 'ca_is_enabled' to json server 'https://auto-hv-01-guest06.testrelm.test/ipa/session/json'
Systemwide CA database updated.
Hostname (cloud-qe-04.testrelm.test) does not have A/AAAA record.
Missing reverse record(s) for address(es): 2620:52:0:1322:3640:b5ff:fe89:616.
Incorrect reverse record(s):
10.19.34.31 is pointing to cloud-qe-04.idmqe.lab.eng.bos.redhat.com. instead of cloud-qe-04.testrelm.test.
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
[try 1]: Forwarding 'host_mod' to json server 'https://auto-hv-01-guest06.testrelm.test/ipa/session/json'
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring testrelm.test as NIS domain.
Client configuration complete.
The ipa-client-install command was successful
[root@cloud-qe-04 ~]# kinit admin
Password for admin:
[root@cloud-qe-04 ~]# klist -ket /etc/gssproxy/http.keytab
Keytab name: FILE:/etc/gssproxy/http.keytab
klist: Key table file '/etc/gssproxy/http.keytab' not found while starting keytab scan
[root@cloud-qe-04 ~]#
[root@cloud-qe-04 ~]# ipa service-add HTTPS/auto-hv-01-guest06.testrelm.test
ipa: ERROR: service with name "HTTPS/auto-hv-01-guest06.testrelm.test" already exists
[root@cloud-qe-04 ~]# ipa service-add HTTP/auto-hv-01-guest06.testrelm.test
ipa: ERROR: service with name "HTTP/auto-hv-01-guest06.testrelm.test" already exists
[root@cloud-qe-04 ~]# klist -ket /etc/gssproxy/http.keytabKeytab name: FILE:/etc/gssproxy/http.keytab
klist: Key table file '/etc/gssproxy/http.keytab' not found while starting keytab scan
[root@cloud-qe-04 ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin
Valid starting Expires Service principal
08/21/2018 11:08:45 08/22/2018 11:06:34 ldap/auto-hv-01-guest06.testrelm.test
08/21/2018 11:08:08 08/22/2018 11:06:34 HTTP/auto-hv-01-guest06.testrelm.test
08/21/2018 11:06:37 08/22/2018 11:06:34 krbtgt/TESTRELM.TEST
[root@cloud-qe-04 ~]# hostname
cloud-qe-04.testrelm.test
[root@cloud-qe-04 ~]# ipa service-add HTTP/cloud-qe-04.testrelm.test
------------------------------------------------------------
Added service "HTTP/cloud-qe-04.testrelm.test"
------------------------------------------------------------
Principal name: HTTP/cloud-qe-04.testrelm.test
Principal alias: HTTP/cloud-qe-04.testrelm.test
Managed by: cloud-qe-04.testrelm.test
[root@cloud-qe-04 ~]# ipa-getkeytab -e des3-cbc-sha1 -s auto-hv-01-guest06.testrelm.test -k /etc/gssproxy/http.keytab -p HTTP/$(hostname -f)
Keytab successfully retrieved and stored in: /etc/gssproxy/http.keytab
[root@cloud-qe-04 ~]# klist -ket /etc/gssproxy/http.keytabKeytab name: FILE:/etc/gssproxy/http.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
1 08/21/2018 11:16:48 HTTP/cloud-qe-04.testrelm.test (des3-cbc-sha1)
#### copy the examples/80-httpd.conf file to /etc/gssproxy/80-httpd.conf... in my case edited file with following details:
-------------
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/gssproxy/http.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = apache
-------------
[root@cloud-qe-04 ~]# cat /etc/gssproxy/80-httpd.conf
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/gssproxy/http.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = apache
[root@cloud-qe-04 ~]# systemctl restart gssproxy.service;systemctl enable gssproxy.service
Created symlink from /etc/systemd/system/multi-user.target.wants/gssproxy.service to /usr/lib/systemd/system/gssproxy.service.
### Run curl command to access IPA-server
[root@cloud-qe-04 ~]# curl -i --negotiate -u : http://auto-hv-01-guest06.testrelm.test/private
HTTP/1.1 401 Unauthorized
Date: Tue, 21 Aug 2018 15:18:30 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_auth_gssapi/1.5.1 mod_auth_kerb/5.4 mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5
WWW-Authenticate: Negotiate
Content-Length: 381
Content-Type: text/html; charset=iso-8859-1
HTTP/1.1 200 OK
Date: Tue, 21 Aug 2018 15:18:30 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_auth_gssapi/1.5.1 mod_auth_kerb/5.4 mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5
WWW-Authenticate: Negotiate YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRv3tJYAErdeEkeRKgDFlaBsv395JA0PSXvMXC3XVebiCzF81MxoxtDNAQrlv/DHJtsxXYMbn5G8S80CZ1w9op7wSU6Ss/63FJb2jntnTO3pK+hb/mWsccJHl9gi3ZBNDtCq3gCAoDG+yIEAdWlHO/j
Last-Modified: Tue, 21 Aug 2018 14:02:15 GMT
Accept-Ranges: bytes
Content-Length: 3
OK
Thus from the above observations, marking the status of bug as VERIFIED.
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://access.redhat.com/errata/RHBA-2018:3070 |
Created attachment 1401418 [details] Patch file Description: Enctype to encrypt/decrypt keys is selected from /etc/krb5.keytab, taking the first encoding type that is permitted by configuration in /etc/krb5.conf. If the selected encoding type is not ENCTYPE_AES256_CTS_HMAC_SHA1_96, function gp_decrypt_buffer fails and gssproxy won't init security context properly. Version-Release number of selected component (if applicable): gssproxy-0.7.0-4.el7.x86_64 How reproducible: Steps to Reproduce: 1. Use any /etc/krb5.keytab with first permitted entry different than aes256-cts-hmac-sha1-96. Example of problematic keytab (klist -kte /etc/krb5.keytab): Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 6 01/01/70 00:00:00 nfs/kclient.example.com (des-cbc-crc) 6 01/01/70 00:00:00 nfs/kclient.example.com (des-cbc-md5) 6 01/01/70 00:00:00 nfs/kclient.example.com (arcfour-hmac) 6 01/01/70 00:00:00 nfs/kclient.example.com (aes256-cts-hmac-sha1-96) 6 01/01/70 00:00:00 nfs/kclient.example.com (aes128-cts-hmac-sha1-96) 2. Make sure permitted_enctypes in /etc/krb5.conf is not set (default encoding types) 3. Mount NFS share as root Actual results: Feb 27 15:21:32 kclient gssproxy[20052]: GSSX_RES_INIT_SEC_CONTEXT( status: { 851968 <None> 2 "Unspecified GSS failure. Minor code may provide more information" "" [ ] } context_handle: <Null> output_token: <Null> ) Here, minor code is 2 which according to KRB5 errors, maps to KRB5_BAD_ENCTYPE. Expected results: No error. Additional info: I've traced the error to file gp_export.c, line 256 (gp_decrypt_buffer), where AES256 enctype is enforced. Find attached a possible patch to fix the issue. I just did some minor testing on my environment and use case, so it's not guaranteed to work in all cases, though it may be useful.