Kerberos API - enhancing program to *force* authentication

[Matt Garman]

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