Keytab-based initiator creds design

[Simo Sorce]

On Thu, 2012-06-07 at 09:15 -0500, Nico Williams wrote:
> I've a very different proposal to make:
> 
> 1) Introduce persistent (/var) and ephemeral (/run) locations for
> per-user keytabs and such:
> 
>  - /{var, run}/krb5/user/$USER/keytab
>  - /{var, run}/krb5/user/$USER/ccache
>  - /{var, run}/krb5/user/$USER/default_principal
>  - ...

In Fedora we are already moving the ccache to a standard place in /run,
and it is non persistent as that filesystem is a tmpfs.

So I think I like this proposal, it aligns well with what we are already
trying to do there.

The /run location should be /run/user/$USER/krb5/ccache though as that
is where the various pam modules put stuff

For the permanent location (for keytab and
default_principal) /var/lib/krb5/user/$USER or similar would probably be
ok.

Should we allow symlinks in the permanent location ?

I am thinking /var/lib/krb5/user/apache/keytab
-> /etc/httpd/conf/apache.keytab

What about default principal ?

I am not 100% convinced we really want ephemeral locations for keytab
and default_principal, or permanent locations for the ccache, but I
wouldn't protest if they were implemented.

> There should be an env var specifying alternative locations.  The
> search order should be:
> 
>  - env var, if present, always wins
>  - ephemeral location
>  - persistent location
>  - traditional default ccache location (/tmp/krb5cc_<uid>) (this needs to
>    be possible to disable in krb5.conf)

I think we want to patch the traditional location out, at least in
Fedora we will probably do so anyway due to tmp name spaces, so I am not
too concerned about it.
Also why do you want them to be disabled ? A user can always go back to
them by setting KRBCCNAME so what's the point ?

> 2) When gss_acquire_cred() is called with desired_name !=
> GSS_C_NO_NAME then acquire a TGT if necessary for the given desired
> name, or, if desired_name == GSS_C_NO_NAME, then acquire a TGT for the
> default principal.  A default principal is: the default principal of
> the user's ccache, if it exists, or the one found in the
> default_principal file, or the principal of the first keytab entry in
> the per-user keytab.
> 
> In fact, some of this logic could be buried deep in libkrb5
> (krb5_get_cred*()) rather than in the mechanism.
> 
> 3) When gss_init_sec_context() is called with then call
> gss_acquire_cred with desired_name == GSS_C_NO_NAME, try to determine
> the correct client principal name to use for the given target name,
> then acquire a credential handle for that name, else acquire a
> credential handle for GSS_C_NO_NAME.
> 
> 4) Always write the credential acquired with a keytab to a ccache if
> possible, but use a memory ccache if there are errors writing to the
> file/dir/ccapi ccache.

Why would we want to use a mem cache in this case ? Wouldn't it be
better to error off ?

> Benefits:
> 
>  - this is fairly simple to understand and probably to implement
>  - this can work for non-GSS krb5 apps too
>  - configurable w/o env vars, but none are required to make it work
>  - low surprise factor: no per-user keytab -> no credential acquisition
>    with keytab
>  - transparent to apps, and even to users if a pam_krb5 should want to
>    setup a keytab for the user in the ephemeral location
>    (a "user" might be an account for application automation, rather than
>    for a human being who is present to interact, in which case the user
>    may well have a keytab in the persistent location, but a ccache in the
>    ephemeral location)
>  - daemons that run with distinct UIDs can have distinct configurations
>  - daemons can also have distinct configurations via env vars should
>    they not run with distinct UIDs

/me nods

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York