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 1639376 - sshd sets wrong value for KRB5CCNAME, code is in Redhat patch
Summary: sshd sets wrong value for KRB5CCNAME, code is in Redhat patch
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.5
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-15 15:17 UTC by hedrick
Modified: 2020-09-25 13:23 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-11 15:41:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.