Bug 690832 - pam_krb5 breaks OpenSSH's recursive credential renewal
Summary: pam_krb5 breaks OpenSSH's recursive credential renewal
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pam_krb5
Version: 6.0
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-25 14:39 UTC by Andreas Haupt
Modified: 2011-12-06 17:35 UTC (History)
2 users (show)

Fixed In Version: pam_krb5-2.3.11-7.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 17:35:42 UTC
Target Upstream Version:


Attachments (Terms of Use)
lightly-tested patch (4.82 KB, patch)
2011-03-28 15:50 UTC, Nalin Dahyabhai
no flags Details | Diff
pkext.patch that fits to pam_krb5-2.3.11-1 (8.89 KB, patch)
2011-03-29 06:33 UTC, Andreas Haupt
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1704 0 normal SHIPPED_LIVE pam_krb5 bug fix update 2011-12-06 01:02:31 UTC

Description Andreas Haupt 2011-03-25 14:39:43 UTC
Description of problem:

pam_krb5 copies the forwarded K5 tickets (delegated by OpenSSH via GSSAPI crentials delegation) into a new credentials cache at login time. OpenSSH in RHEL6 now offers a new feature that renews credentials on remote hosts (activated with GSSAPIRenewalForcesRekey), if they are renewed on the client.

Version-Release number of selected component (if applicable):

pam_krb5-2.3.11-1.el6.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. Activate GSSAPIAuthentication, GSSAPIDelegateCredentials, GSSAPIStoreCredentialsOnRekey & GSSAPIRenewalForcesRekey in OpenSSH
2. Login to an ssh server using successful GSSAPI authentication.
3. Look at the two generated KRB5CCNAME files.

Log (server runs in debug mode):

[oreade38] ~ % ssh <host>
[...]
debug1: Setting KRB5CCNAME to FILE:/tmp/krb5cc_9132_XMrKz14666
debug3: Copy environment: KRB5CCNAME=FILE:/tmp/krb5cc_9132_gyy9DB
debug3: Copy environment: SELINUX_ROLE_REQUESTED=
debug3: Copy environment: SELINUX_LEVEL_REQUESTED=
debug3: Copy environment: SELINUX_USE_CURRENT_RANGE=
Environment:
  KRB5CCNAME=FILE:/tmp/krb5cc_ahaupt_gyy9DB
[...]

/tmp/krb5cc_9132_XMrKz14666 has been created by OpenSSH (delegated creds), /tmp/krb5cc_9132_gyy9DB has been created by pam_krb5. Only /tmp/krb5cc_9132_XMrKz14666 gets updated in case of creds renewal.

Actual results:

After login there are two different K5 caches available.

Expected results:

There should be only one K5 cache - the one, OpenSSH has created. This one should also be used for generating AFS tokens, etc.

Additional info:

Comment 2 Nalin Dahyabhai 2011-03-25 15:41:39 UTC
If you don't need AFS tokens, you can set "no_external = sshd" in the "pam" portion of the [appdefaults] section of /etc/krb5.conf to disable the behavior and work around this.  A proper fix will take a bit longer.

Comment 4 Andreas Haupt 2011-03-28 14:05:35 UTC
Hi Nalin,

thanks. Unfortunately we need AFS tokens. But I could workaround the problem with your tip and the usage of pam_afs_session.

Comment 5 Nalin Dahyabhai 2011-03-28 15:50:35 UTC
Created attachment 488185 [details]
lightly-tested patch

Comment 6 Nalin Dahyabhai 2011-03-28 15:51:43 UTC
(In reply to comment #4)
> Hi Nalin,
> 
> thanks. Unfortunately we need AFS tokens. But I could workaround the problem
> with your tip and the usage of pam_afs_session.

Ah, I didn't know if you were mentioning AFS for completeness or if you actually needed it.  I'm attaching a lightly-tested patch which I think will fix this properly.  If you're in a position to test it, that'd be great.  Thanks!

Comment 7 Andreas Haupt 2011-03-29 06:33:39 UTC
Created attachment 488335 [details]
pkext.patch that fits to pam_krb5-2.3.11-1

Comment 8 Andreas Haupt 2011-03-29 06:39:27 UTC
Hi Nalin,

thanks for the patch. I had to slightly modify it, though (attached):

[blade8e] /tmp/pam_krb5-2.3.11-1 % patch -p1 < ../rpm-ahaupt/SOURCES/pkext.patch 
patching file src/session.c
patching file src/stash.c
patching file src/stash.h
Hunk #1 FAILED at 43.
1 out of 1 hunk FAILED -- saving rejects to file src/stash.h.rej
[blade8e] /tmp/pam_krb5-2.3.11-1 % cat src/stash.h.rej
--- src/stash.h
+++ src/stash.h
@@ -43,7 +43,7 @@
 struct _pam_krb5_stash {
 	char *key;
 	krb5_context v5ctx;
-	int v5attempted, v5result, v5expired;
+	int v5attempted, v5result, v5expired, v5external;
 	struct _pam_krb5_ccname_list *v5ccnames;
 	krb5_creds v5creds;
 	int v5setenv;

But it works! Now I still have the problem, that pam_krb5 doesn't renew the AFS tokens when fresh K5 credentials arrive. But this is another problem.

[blade8e] /root # cat /etc/pam.d/sshd-rekey 
#%PAM-1.0
auth       optional     pam_krb5.so
session    optional     pam_krb5.so

Replacing pam_krb5 with pam_afs_session here does the jobs again ... ;-)

Cheers,
Andreas

Comment 9 Nalin Dahyabhai 2011-03-29 14:20:14 UTC
(In reply to comment #8)
> But it works! Now I still have the problem, that pam_krb5 doesn't renew the AFS
> tokens when fresh K5 credentials arrive. But this is another problem.

Hmm.  I hadn't checked if sshd reinitializes creds when it rekeys, but what you're seeing suggests that it does (unless it's closing and opening the session again, which would be kind of weird).  That'll have to take a while, since I'm tied up with other things at the moment.

Thanks!

Comment 12 Nalin Dahyabhai 2011-07-29 19:08:37 UTC
Okay, a couple of other things that needed to be done:
 * when called to reinitialize creds with the "external" option, the module needs to reimport the externally-supplied creds and use them
 * also stop removing ccache files when the "external" option is used

Comment 15 errata-xmlrpc 2011-12-06 17:35:42 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.

http://rhn.redhat.com/errata/RHBA-2011-1704.html


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