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 1153011 - sshd requires that .k5login exists even if krb5_kuserok() returns TRUE
Summary: sshd requires that .k5login exists even if krb5_kuserok() returns TRUE
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Petr Lautrbach
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On:
Blocks: 1160384
TreeView+ depends on / blocked
 
Reported: 2014-10-15 11:31 UTC by Sumit Bose
Modified: 2015-03-05 09:28 UTC (History)
6 users (show)

Fixed In Version: openssh-6.6.1p1-4.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1160384 (view as bug list)
Environment:
Last Closed: 2015-03-05 09:28:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Patch (8.99 KB, patch)
2014-10-21 19:28 UTC, Sumit Bose
no flags Details | Diff
Patch (8.99 KB, patch)
2014-10-21 19:38 UTC, Sumit Bose
sbose: review?
Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0425 0 normal SHIPPED_LIVE Moderate: openssh security, bug fix and enhancement update 2015-03-05 14:26:20 UTC

Description Sumit Bose 2014-10-15 11:31:09 UTC
Description of problem:
When using GSSAPI authentication sshd has to check if the principal from the Kerberos ticket is allowed to log in as the given user. MIT Kerberos provides a number of schemes to do this including configurable plugins and checking the .k5login file.

A quite old patch in the RHEL version of openssh checks for the existence of .k5login unconditionally and hence prevents other mechanisms to be used properly.

I will attach a patch for this issue to this ticket during the next week.

Comment 3 Sumit Bose 2014-10-21 19:28:44 UTC
Created attachment 949094 [details]
Patch

Comment 4 Sumit Bose 2014-10-21 19:36:33 UTC
Please find attached a patch which fixes this issue for me and hopefully does not change any other existing behavior. I added some explanations of my findings and my thoughts about the current state of the related code and patches. I add it here as well for easier reference:

The purpose of the function is to find out if a Kerberos principal is
allowed to log in as the given local user. This is a general problem with
Kerberized services because by design the Kerberos principals are
completely independent from the local user names. This is one of the
reasons why Kerberos is working well on different operating systems like
Windows and UNIX/Linux. Nevertheless a relationship between a Kerberos
principal and a local user name must be established because otherwise every
access would be granted for every principal with a valid ticket.

Since it is a general issue libkrb5 provides some functions for
applications to find out about the relationship between the Kerberos
principal and a local user name. They are krb5_kuserok() and
krb5_aname_to_localname().

krb5_kuserok() can be used to "Determine if a principal is authorized to
log in as a local user" (from the MIT Kerberos documentation of this
function). Which is exactly what we are looking for and should be the
preferred choice. It accepts the Kerberos principal and a local user name
and let libkrb5 or its plugins determine if they relate to each other or
not.

krb5_aname_to_localname() can use used to "Convert a principal name to a
local name" (from the MIT Kerberos documentation of this function). It
accepts a Kerberos principle and returns a local name and it is up to the
application to do any additional checks. There are two issues using
krb5_aname_to_localname(). First, since POSIX user names are case
sensitive, the calling application in general has no other choice than
doing a case-sensitive string comparison between the name returned by
krb5_aname_to_localname() and the name used at the login prompt. When the
users are provided by a case in-sensitive server, e.g. Active Directory,
this might lead to login failures because the user typing the name at the
login prompt might not be aware of the right case. Another issue might be
caused if there are multiple alias names available for a single user. E.g.
the canonical name of a user is user.example.com but there
exists a shorter login name, e.g. user, to safe typing at the
login prompt. Here krb5_aname_to_localname() can only return the canonical
name, but if the short alias is used at the login prompt authentication
will fail as well. All this can be avoided by using krb5_kuserok() and
configuring krb5.conf or using a suitable plugin to meet the needs of the
given environment.

The Fedora and RHEL version of openssh contain two patches which modify the
access control behavior:
 - openssh-6.6p1-kuserok.patch
 - openssh-6.6p1-force_krb.patch

openssh-6.6p1-kuserok.patch adds a new option KerberosUseKuserok for
sshd_config which controls if krb5_kuserok() is used to check if the
principle is authorized or if krb5_aname_to_localname() should be used.
The reason to add this patch was that krb5_kuserok() by default checks if
a .k5login file exits in the users home-directory. With this the user can
give access to his account for any given principal which might be
in violation with company policies and it would be useful if this can be
rejected. Nevertheless the patch ignores the fact that krb5_kuserok() does
no only check .k5login but other sources as well and checking .k5login can
be disabled for all applications in krb5.conf as well. With this new
option KerberosUseKuserok set to 'no' (and this is the default for RHEL7
and Fedora 21) openssh can only use krb5_aname_to_localname() with the
restrictions mentioned above.

openssh-6.6p1-force_krb.patch adds a ksu like behaviour to ssh, i.e. when
using GSSAPI authentication only commands configured in the .k5user can be
executed. Here the wrong assumption that krb5_kuserok() only checks
.k5login is made as well. In contrast ksu checks .k5login directly and
does not use krb5_kuserok() which might be more useful for the given
purpose. Additionally this patch is not synced with
openssh-6.6p1-kuserok.patch.

The current patch tries to restore the usage of krb5_kuserok() so that e.g.
localauth plugins can be used. It does so by adding a forth parameter to
ssh_krb5_kuserok() which indicates whether .k5login exists or not. If it
does not exists krb5_kuserok() is called even if KerberosUseKuserok is set
to 'no' because the intent of the option is to not check .k5login and if it
does not exists krb5_kuserok() returns a result without checking .k5login.
If .k5login does exists and KerberosUseKuserok is 'no' we fall back to
krb5_aname_to_localname(). This is in my point of view an acceptable
limitation and does not break the current behaviour.

Additionally with this patch ssh_krb5_kuserok() is called in
ssh_gssapi_krb5_cmdok() instead of only krb5_aname_to_localname() is
neither .k5login nor .k5users exists to allow plugin evaluation via
krb5_kuserok() as well.

I tried to keep the patch as minimal as possible, nevertheless I see some
areas for improvement which, if they make sense, have to be evaluated
carefully because they might change existing behaviour and cause breaks
during upgrade:
- I wonder if disabling .k5login usage make sense in sshd or if it should
  be better disabled globally in krb5.conf
- if really needed openssh-6.6p1-kuserok.patch should be fixed to really
  only disable checking .k5login and maybe .k5users
- the ksu behaviour should be configurable and maybe check the .k5login and
  .k5users files directly like ksu itself does
- to make krb5_aname_to_localname() more useful an option for sshd to use
  the canonical name (the one returned by getpwnam()) instead of the name
  given at the login prompt might be useful

Comment 5 Sumit Bose 2014-10-21 19:38:02 UTC
Created attachment 949096 [details]
Patch

Comment 10 errata-xmlrpc 2015-03-05 09:28:30 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/RHSA-2015-0425.html


Note You need to log in before you can comment on or make changes to this bug.