Default libkrb5 ccache location

[Simo Sorce]

On Sat, 2013-07-27 at 18:23 +0200, Lennart Poettering wrote:
> 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?

We create /run/user/$UID if missing, then spawn child process helper
which setuids to $UID and runs kerberos code which will
create /run/user/$UID/krb5cc as needed as $UID.

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

We try to be careful, feel free to review SSSD code and communicate any
issue you may see in that area.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York