Bug 1639376

Summary:	sshd sets wrong value for KRB5CCNAME, code is in Redhat patch
Product:	Red Hat Enterprise Linux 7	Reporter:	hedrick
Component:	openssh	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	low
Version:	7.5	CC:	a.korsunsky, jhrozek, nmavrogi, o.freyermuth
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-02-11 15:41:21 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:

Description hedrick 2018-10-15 15:17:02 UTC

on a system with Kerberos credentials, ssh to a 7.5 system. That is, login is with Kerberos, not a password prompt.

sshd correctly checks the Kerberos credentials and logs you in. However KRB5CCNAME is now set to the name of the credential cache. This is inconsistent with sssd behavior, and will cause trouble for anyone using kswitch. It's also inconsistent with the intended behavior of the new KCM: code.

If the credential type supports collections, and default_ccname in krb5.conf is set to a collection, sssd will set KRB5CCNAME to the collection to which the new credential belongs. sshd will set it to the actual credential. The difference is that if it's set to the collection, you can use kswitch. With the actual credential you can't. The code to do this for sssd is in krb5_ccache.c. It checks krb5_cc_support_switch for the credential type to see whether the collection should be used. The openssh code is in openssh-7.4p1-gsskex.patch. It simply sets the name to the current value of krb5_cc_get_name of the cache. That line needs to be replaced by login similar to what's in sssd.

There's a second issue with your patch. With the original code, sshd always generated a new credential cache, stored in /tmp. Suppose you kinit to user.admin to do administrative work, but login a second time using Kerberos. WIth the original code there's no problem. The new login gets a new credential cache, and has no effect on the other process. But with your patch, the new login uses the primary cache for the user's collection, thus overwriting credentials for user.admin with credentials for user. The behavior should be consistent with kinit, which checks to see whether the principal matches the principal for the primary credential cache. If not, it generates a new credential cache. Thus it doesn't overwrite the existing credential. sshd also avoids overwriting an existing credential.

Comment 2 hedrick 2018-10-15 15:30:56 UTC

sorry, code for sssd is not entirely in krb5_ccache.c. Unfortunately it's not in any one place, so it can't just be copied into sshd.

Comment 3 Jakub Jelen 2018-10-16 09:49:17 UTC

    Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to  guarantee the timeliness or suitability of a resolution.

     

    If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain  it receives the proper attention and prioritization to assure a timely resolution. 

     

    For information on how to contact the Red Hat production support team, please visit:

    https://www.redhat.com/support/process/production/#howto

Morover, some of you already described is already handled in the bugs #1566494 (private) and #1278017 as well as in the upstream bug [1] so any feedback or improvements to the proposed code would be very appreciated.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2775

Comment 4 hedrick 2018-10-17 15:11:46 UTC

This is not a request for support. I'm perfectly capable of fixing this for our own systems. This is a report of a problem with the behavior of the software. I'd actually prefer for it to be handled upstream. You're proposed some patches, but I checked in the upstream source and I don't see anything. Hence my question in the upstream bugzilla about the status of this issue.

I'll try to apply the patch and see if it fixes things, if the patch is still live.

Comment 5 hedrick 2018-10-17 15:21:11 UTC

Actually it's not clear to me just what code to check. There are two patches upstream, and you seem to be referring to two Redhat patches, one private. What code would you like me to check?

Comment 6 Jakub Jelen 2018-10-18 08:49:03 UTC

This is indeed a support request to get a bug fixed, which we do for our customers. But I appreciate your willingness to contribute back.

Unfortunately, the OpenSSH upstream is not very willing to fix bugs or improve certain parts of the code they are not very familiar with or not matching their OpenBSD use cases.

It looks like you already figured out how to check and test the code so thank you for your comments. I will try to have a look into them to address them.

Comment 8 Simo Sorce 2019-02-11 15:41:21 UTC

This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.