Kerberos API - enhancing program to *force* authentication

[Russ Allbery]

Matt Garman <matthew.garman at 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 (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>