Default libkrb5 ccache location

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/26/2013 02:52 PM, Lennart Poettering wrote:
> On Fri, 26.07.13 14:32, Stephen Gallagher (sgallagh at redhat.com)
> wrote:
> 
>> As Simo noted in the other thread, the availability of
>> credentials outside the normal user session is an expectation of
>> existing tools. The exposure here is significantly mitigated by
>> the fact that Kerberos credentials are time-limited by the KDC.
> 
> So, let me get this right: you want a host-specific tmpfs location
> which is never automatically cleaned up, but is a private namespace
> of the user (though the system sometimes writes to it), correct?
> 
> That really sounds like a step backwards. Defining new runtime dirs
> without immediately thinking about life-cycles is something we
> really shouldn't do anymore.
> 
> XDG_RUNTIME_DIRS was introduced just because we want a clear 
> life-cycle.
> 
> Lennart
> 
> PS: as a side note. what do you actually create in XDG_RUNTIME_DIR?
> A subdirectory?  You are aware of the inherent risks of sharing a 
> directory between system code and user code? It's extremely hard
> to properly get a subdir created in such a dir without opening a
> security hole.
> 

Yes, we're creating a directory that will contain within it one or
more file-based credential caches along with a special file that tells
libkrb5 which one is the active default at a particular time. The
actual cache directory is *never* created by system code. It's always
generated by the libkrb5 in the user context. What *may* be created by
the system is the enclosing directory. In the current situation, SSSD
(as root) creates /run/user/UID and then libkrb5 creates
/run/user/UID/krb5cc.

What we're looking for is a more generic way to have a root process
create the containing directory (either /run/user/UID or
/run/kerberos/UID as appropriate).


> PPS: if you give up on the unrestricted life-cycle and hence do
> still want to use XDG_RUNTIME_DIR, and you don't want to pre-create
> the dir on your own: you could just stick the cred cache into some
> PAM context var instead of writing it to XDG_RUNTIME_DIR right
> away, and then write it to the fs only at the very last step, long
> after pam_systemd set it up for you. sshd could place its creds
> there, and the PAM auth modules could add more into it, and then as
> last step you just flush all that was collected to the dir. This
> would be quite nice given that that way an aborted PAM sessions
> setup could never leave the half setup pre-created dir around.
> 


I talked about a similar approach on IRC today with Nalin and Ray
Strode, but there's another edge-case problem there with
pam_afs_session.so which will make a copy of the KRB5CCNAME env var
during its execution (and consumes credentials from that location), so
we can't just hold onto the creds and write them later, unfortunately.


<halfline_laptop> maybe the credentials should be stuffed away in a
MEMORY credential cache type tucked away in an AUTHTOK for PAM modules
to use until pam_open_session time
<halfline_laptop> when it can get serialized to XDG_RUNTIME_DIR
<halfline_laptop> i guess "rewrite all the pam modules" isn't a very
effective answer
<sgallagh> Well, they wouldn't necessarily need to be rewritten
<sgallagh> As long as the KRB5CCNAME env var is set properly, they
should just be using that.
<sgallagh> I'm not sure how clean a transition we could make in
pam_open_session, though
<halfline_laptop> yea i guess the problem is afs or whatever would
still be looking in the old cache after the transition
<sgallagh> exactly
<halfline_laptop> so we'd need to make sure the afs session module
told afs about the new location
<halfline_laptop> -> back to rewriting all the pam modules
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHyx/AACgkQeiVVYja6o6PyXACeOyZVRPufgsqzsPTuaUvTMkQE
cDkAn2ktmoB7SGXQNWICnYNkaYrU7LvE
=T02s
-----END PGP SIGNATURE-----