On Sat, 2013-07-27 at 18:23 +0200, Lennart Poettering wrote: > On Fri, 26.07.13 15:03, Stephen Gallagher (sgallagh@xxxxxxxxxx) 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@xxxxxxxxxx) > > > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
