Bug 848228 - please store Kerberos credentials in locations other than /tmp
please store Kerberos credentials in locations other than /tmp
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-14 19:28 EDT by Nalin Dahyabhai
Modified: 2013-06-18 02:13 EDT (History)
10 users (show)

See Also:
Fixed In Version: openssh-6.2p2-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-18 02:13:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
use kerberos5 DIR cache storage (4.47 KB, patch)
2012-09-12 10:57 EDT, Petr Lautrbach
no flags Details | Diff

  None (edit)
Description Nalin Dahyabhai 2012-08-14 19:28:27 EDT
Description of problem:

As part of the Fedora 18 features https://fedoraproject.org/wiki/Features/KRB5CacheMove and https://fedoraproject.org/wiki/Features/KRB5DirCache, we'd like to have sshd store a user's Kerberos credentials in the per-user /run/user/$UID directory.

Specifically, instead of using "FILE:/tmp/krb5cc_%d_XXXXXXXXXX" and generating a file name based on it, I'd suggest first attempting "DIR:/run/user/%d/krb5cc_XXXXXXXX", possibly falling back to the current template if that doesn't work for some reason (such as /run/user not being there).  It's a bit more complicated, but hopefully not too much so.

Version-Release number of selected component (if applicable):
openssh-6.0p1-1.fc18

How reproducible:
Authenticate to sshd using either GSSAPIAuthentication with delegation enabled from the client, or with KerberosAuthentication.  $KRB5CCNAME should point to a location under /run/user/%d, preferably of type "DIR:".
Comment 1 Nalin Dahyabhai 2012-08-16 14:29:24 EDT
To clarify, the complications I alluded to include:
* In krb5 1.10, the libraries don't create the directory if it doesn't exist when you go to initialize a ccache with krb5_cc_resolve() and krb5_cc_initialize(), but 1.11's libraries will.  The 1.11 release is currently scheduled for after the F18 freeze, so if we make this change we'll have to at least do the mkdir() from inside of sshd.
* The library's krb5_cc_destroy() may leave other files and the directory around, even when it returns successfully.  The best you can probably do is remove files named "primary" or which have names that start with "tkt" from the directory, and then attempt to rmdir() the directory itself, either after or instead of calling krb5_cc_resolve()/krb5_cc_destroy().
Comment 2 Nalin Dahyabhai 2012-09-04 16:52:32 EDT
Any news here?  I'm trying to get a better idea of where we are for the feature in general.
Comment 3 Petr Lautrbach 2012-09-05 11:14:26 EDT
I'm sorry, I've had something else to do but I'll look at it tommorow.
Comment 4 Petr Lautrbach 2012-09-06 12:45:26 EDT
I've found an issue while I was testing sshd with sssd and kerberos authentication.
/run/user/<UID> directory is created by pam_systemd which is run during session part of pam after authentication. 
So I see several pam_krb5 error messages before pam_systemd is run:

Sep  6 18:19:14 rawhide sshd[2137]: pam_krb5[2137]: TGT verified
Sep  6 18:19:14 rawhide sshd[2139]: pam_krb5[2139]: error copying credentials from "MEMORY:_pam_krb5_tmp_s_plautrba@REDHAT.COM-0" to "FILE:/run/user/13558/krb5cc_fcLQBI" for the user
Sep  6 18:19:14 rawhide sshd[2137]: pam_krb5[2137]: authentication succeeds for 'plautrba' (plautrba@REDHAT.COM)
Sep  6 18:19:14 rawhide sshd[2140]: pam_krb5[2140]: error copying credentials from "MEMORY:_pam_krb5_tmp_s_plautrba@REDHAT.COM-0" to "FILE:/run/user/13558/krb5cc_lo7G1P" for the user
Sep  6 18:19:14 rawhide sshd[2137]: Accepted password for plautrba from 192.168.122.1 port 54816 ssh2
Sep  6 18:19:14 rawhide sshd[2137]: pam_systemd(sshd:session): Asking logind to create session: uid=13558 pid=2137 service=sshd type=tty seat= vtnr=0 tty=ssh display= remote=yes remote_user= remote_host=master.virt
...

It might be same for GSSAPIAuthentication but I can't confirm it right now and I'll do more 
investigation.
Comment 5 Nalin Dahyabhai 2012-09-06 16:34:35 EDT
(In reply to comment #4)
> I've found an issue while I was testing sshd with sssd and kerberos
> authentication.
> /run/user/<UID> directory is created by pam_systemd which is run during
> session part of pam after authentication. 
> So I see several pam_krb5 error messages before pam_systemd is run:

Yes, the changes to pam_krb5 are currently in-progress as well.  But then if you're dealing with PasswordAuthentication you probably want to be turning on KerberosAuthentication rather than letting pam_krb5 deal with creating them.

> It might be same for GSSAPIAuthentication but I can't confirm it right now
> and I'll do more 
> investigation.

Right, the cases I expect sshd to need to be updated for are the ones where it's directly creating credential caches, in contrast to cases where it's letting PAM do it (pam_krb5, pam_sss, maybe pam_winbind) - that's the PasswordAuthentication-with-KerberosAuthentication and GSSAPIAuthentication methods, unless I'm missing something.  The docs for KerberosAuthentication tell me that the SSH server will need a keytab while testing it, and that's true for GSSAPIAuthentication as well.

Probably the least manually-intensive way we have available to bring up a KDC, create the right entry in its realm database, and set up a keytab, is to configure a system as an IPA server (install freeipa-server, run ipa-server-install, then "ipa user-add" to add a client user).  The test user should then be able to ssh from the server to itself (using its FQDN) using either their password or "kinit" and GSSAPI authentication.
Comment 6 Petr Lautrbach 2012-09-07 04:18:57 EDT
My main concern is that a /run/user/<UID> directory is created during the start of session
which is after the authentication when kerberos cache files are created. 
And I'm in doubt whether the openssh server or any other daemon
should create this directory if it doesn't exist.
Comment 7 Nalin Dahyabhai 2012-09-07 10:28:11 EDT
It might have to -- I only see session management functions being exported by the pam_systemd.so module, which I believe usually handles this step.  sshd skips pam_authenticate() for pubkey and GSSAPI authentication, so having the module create the directory in its pam_sm_authenticate() method wouldn't help us, and anyway I can understand avoiding creating a directory just because we're checking a password.

Care would have to be taken to ensure the right permissions (both traditional and SELinux) were applied to any directories that sshd created. Since I'd like to avoid adding logic, that would have to be maintained, to create that directory everywhere, having sshd create it wouldn't be my first choice.

In the short-term, while we look for a different solution, we could land the "DIR:" part of this now and leave the "move" part for later.  I don't see https://fedoraproject.org/wiki/Features/Polyinstantiated_Temporary_Directories landing in F18, and that removes much of the urgency of the "move" part of things.  So sshd might want to continue to create caches in /tmp, as nfs-utils and cifs-utils will still know to look there.
Comment 8 Dmitri Pal 2012-09-07 10:36:17 EDT
Nalin,

I disagree. IMO the move part is required for F18 for all components that create the cache. It is not an option and needs to be addressed. So please find a way to create a directory.

Thanks
Dmitri
Comment 9 Tomas Mraz 2012-09-07 13:05:01 EDT
Perhaps the krb5 ccache code could ask systemd somehow to create the directory?
Comment 10 Dmitri Pal 2012-09-07 13:46:05 EDT
The MIT code can potentially add a callback to create directory for the cred storage before placing the cache there. It then would have to have a platform specific implementation. In Fedora and derivatives it call call out to systemd. 

Is this the way to go if so we need to talk to MIT to create such callback interface?
Comment 11 Nalin Dahyabhai 2012-09-07 14:27:56 EDT
(In reply to comment #9)
> Perhaps the krb5 ccache code could ask systemd somehow to create the
> directory?

That assumes that the location in question is one that systemd is in the business of creating, and that systemd provides a method for asking it to do so.

But a simpler question (and the one I've CC'd the systemd maintainers for input on) is: how we can trigger creation of a user's XDG_RUNTIME_DIR without having to call pam_open_session() or making a CreateSession method call?
Comment 12 Petr Lautrbach 2012-09-12 10:57:38 EDT
Created attachment 612140 [details]
use kerberos5 DIR cache storage

This patch changes type of used kerberos credential cache to DIR type according to the KRB5DirCache feature. I'll probably going to somehow merge it into the existing openssh-5.9p1-gsskex.patch as openssh-6.0p1-gsskex.patch but first I'd like to ask for review these particular changes.

The template for kerberos authentication has been changed to "DIR:/tmp/krb5cc_%d_XXXXXXXXXX", a directory is created instead of file. In cleanup, there's first check of existence of a primary file in the directory which is then removed and rmdir() is attempted.
Similar actions are done also in GSSAPI session cleanup.
Comment 13 Lennart Poettering 2012-09-13 15:17:52 EDT
(In reply to comment #6)
> My main concern is that a /run/user/<UID> directory is created during the
> start of session
> which is after the authentication when kerberos cache files are created. 
> And I'm in doubt whether the openssh server or any other daemon
> should create this directory if it doesn't exist.

It's OK if kerberos pre-creates the dir for pam_systemd. If it already exists it will not be deleted and things should be safe for kerberos. However, when the last session of the user ends the dir is entirely removed. Which is a good thing I presume.

I'd suggest kerberos simply creates the dir and we add no further coupling between kerbereos and systemd. Howerver i can also add a D-Bus call for you guys you can invoke which simply creates the dir.

To create the dir pam_systemd/logind does:

mkdir_p("/run/user/$UID", 0700);
chown("/run/user/$UID", $UID, $GID);
selinux_relabel("/run/user/$UID");

And that's it. If you do the same in kerberos pam_systemd/logind will just take over that dir and continue using it.
Comment 14 Fedora Update System 2012-09-15 12:33:10 EDT
openssh-6.1p1-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openssh-6.1p1-1.fc18
Comment 15 Fedora Update System 2012-09-16 15:15:49 EDT
Package openssh-6.1p1-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-6.1p1-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-13976/openssh-6.1p1-1.fc18
then log in and leave karma (feedback).
Comment 16 Fedora Update System 2012-09-23 23:25:49 EDT
openssh-6.1p1-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Fedora End Of Life 2013-04-03 15:38:39 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 18 Fedora Update System 2013-06-17 11:50:54 EDT
openssh-6.2p2-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openssh-6.2p2-3.fc19
Comment 19 Fedora Update System 2013-06-18 02:13:39 EDT
openssh-6.2p2-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

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