Matt Garman <matthew.gar...@gmail.com> writes: > - Will forcing the retrieval of a new ticket interfere in any way > with the user's current credentials (or his credentials cache)? The > main reason we currently have Kerberos implemented is for Kerberized > NFSv4 home directories (i.e. sec=krb5p NFS mount option). So as I > suggested above, the user will already have valid Kerberos ticket and > credentials cache (otherwise they'll be "permission denied" out of > their own home dir). I don't want to interfere with those, just > authenticate that the person using this program is really who he says > he is.
You'll want to either perform just the authentication calls without saving the resulting cache or use a separate cache (by setting KRB5CCNAME to override the default cache, only for this interaction). > - I'm just getting started with familiarizing myself with the > Kerberos API, but already I see that's a fairly low-level way to > achieve my goal. I.e., some of my reading suggests using GSS-API, > SASL+TSL, etc might be a more "generic" approach... any thoughts on > this, given my use case? You probably want to just call krb5_get_init_creds_password. Preferrably you would do this via PAM rather than doing any direct Kerberos integration yourself, and just use the system PAM Kerberos module. Note that this requires the user to enter their password into your application, so ideally from a Kerberos perspective this application would only run on their local system (the one physically attached to the keyboard they're typing into). Anything else is a (partial) weakening of the Kerberos security model, since the long-term user keys should never leave the local system. But practical deployments of Kerberos do tend to violate this all the time, so.... > Lastly, FWIW, the program we want to integrate with Kerberos is tmux > (same concept as GNU Screen). tmux allows terminals to be "detached" > and "reattached" (e.g. detach, go home, login remotely, attach to get > your exact same terminal(s) back). What we want is to force a Kerberos > authentication whenever an "attach" is attempted. This is to prevent > admins (i.e. root user) from su'ing to that user, then attaching to his > console (and why we don't want to use existing credentials, but force > password entry). I assume you're using SELinux or some other MAC system to significantly restrict the capabilities of root? Otherwise, root users can just replace your tmux binary with their own that doesn't have this check and bypass all of your checks, so this is, from a security standpoint, kind of pointless. It's just security via obscurity. If you are using SELinux, it might be easier to just not give root access to the tmux sockets. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
