Default libkrb5 ccache location

[Lennart Poettering]

On Fri, 26.07.13 15:03, Stephen Gallagher (sgallagh at redhat.com) wrote:

> -----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.

So, /run/user/$UID/krb5cc/ is a directroy you say is not created by
system code, but by user code. Yet you say that you need this very early
in the PAM chain, which however is in code that runs with full
privileges as system code. This seems to contradict? Can you elaborate?

If you create /run/user/$UID/krb5cc/ from privileged code then it is
very easy for unprivileged code to exploit that unless you are extra
careful.

> 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.

Well, you could fix pam_afs_session.so, too, no? I mean this is all open
source, and under your control. Instead of adding work-arounds to
systemd/logind and friends it sounds pretty OK to fix
pam_afs_session.so, ssh and the krb pam module instead.

> <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

Well, it's not all PAM modules, it's just the few which use kerberos
tickets...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.