Hi Russ, thank you for the (as always) very helpful and detailed reply... a few follow-up comments:
On Wed, Feb 3, 2016 at 4:47 PM, Russ Allbery <ea...@eyrie.org> wrote: > 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). > > [ ... ] > > 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. Since sending that I basically did exactly what you suggest, more or less copying the krb5_init source, but stripping out any cache-related stuff. I also request a very short-lived ticket life (30s). So far seems pretty straightforward! > 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.... Oh we violate this on a regular basis! Our Linux environment is all rackmount servers in a remote facility, and none have keyboards attached (except in special maintenance situations). But all access is through ssh, so I believe Kerberos keys (or anything sensitive for that matter) should never pass through the network un-encrypted. > 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. Not currently, but now that you mention it, it's probably time I sit down and learn it (SELinux that is). To be honest, I've always been scared of it. But: if a root user can drop in a fake binary, can't he also twiddle the SELinux policy as well? (Exposing my gross ignorance of SELinux here.) On the other hand, our environment is such that it would be fairly hard to actually produce a non-desired binary, as Internet access is basically non-existent, and the vanilla source (tmux or other program) would be secured in a inaccessible vault. We acknowledge that there will likely always be holes, just trying to plug the known ones and set up as many safeguards as possible. Good stuff to think about, I appreciate it! It's refreshing to hear someone give useful technical advice, rather than just repeat the "fix your hiring practices" line. Thanks again! Matt ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
