Re: KRB5CCNAME new semantics under Maverick?

On 04/30/2014 06:14 AM, Lars-Johan Liman wrote:
> Hmm. What does "is a ccache in the collection for that principal" mean?
> 
> Which collection? How is it the content of the collection determined?

"The collection" is the aggregate of all per-type collections.  The
per-type collections are defined as follows (if I remember correctly):

* FILE: if the default cache is a FILE cache, that cache
* DIR: if the default cache is a DIR cache, the caches within that directory
* API/KCM: all of the caches held by the KCM daemon which are accessible
to the process's uid
* MEMORY: all of the memory caches created by the process

So in typical circumstances, "the collection" is the KCM daemon's caches
for the user plus the default FILE or DIR cache.

> This bullet "1." only kicks in when a ticket for that principal already
> exists, right?

Yes.

>> 2. If the default ccache type supports switching, make a new ccache.
> 
> ... which can be futhered narrowed down to "if the default ccache is
> API:, make a new ccache", right

Or KCM: or DIR:  (KCM: is basically the same as API: in a typical build.
 DIR: references a directory containing a bunch of file ccaches and a
file indicating which one is the default.)

> (because FILE: doesn't support switching (why not?))?

FILE:/path/to/file refers to exactly one ccache.  There is no way to
"switch the default cache" within a singleton.

>> 3. Otherwise, use the default ccache (KRB5CCNAME or system default).
> 
> ... and how is the default ccache determined?

In order of preference:

1. (OSX only) $KRB5CCPRINCIPAL if it is set and matches a cache in the
collection.
2. $KRB5CCNAME if it is set.
3. default_cc_name in [libdefaults] in the profile, as expanded by path
tokens, if it is set.
4. The default name for the default cache type (which is API: on OSX).

(1) and (2) are skipped when issuid() is true.  The per-cache type name
for API: is determined by a query to the KCM daemon.

> How do I force a specific application (say telnet, for want of a better
> example) to use a specific ccache?

That depends on what the application does.

If an application uses the default ccache and isn't setuid, then setting
KRB5CCNAME will suffice.

If an application uses GSSAPI with a specified initiator name (not very
common), the collection will be searched for a ccache of that name.

If an application goes out of its way to use a specific ccache somehow,
like kinit does, then you have to understand how it picks one and how
you can influence its behavior (like kinit -c).

> Also, how do I _prevent_ an application from looking in _another_ cc
> than the one I want it to look in? Is setting KRB5CCNAME enough to avoid
> having its eyes to astray (using the system Kerberos libs).

No.  A ccache is just a named container.  Asking for a trivial way to
restrict the ccaches an application will use is like asking for a
trivial way to restrict the files an application will use.
Most of the time, setting the default ccache will suffice.

> And, more important: with the behaviour I described in my post, I feel
> like there is "suddenly" a security issue involved.
[...]

I can't follow your scenario exactly.  If you create a new ccache as
root, I would not expect it to be readable to other uids, nor would I
expect the default to be switched for other uids, but I might be missing
something.

> b) A change vs. earlier (MIT) behaviour, which gives ppl (like me) a
>    very false feeling of security. "In this shell I'm using a different
>    cc, so there's no chance the tickets will be mixed." ... NOT. :-(

A reasonable criticism, but there are competing pressures.  People want
to be able to conveniently use multiple client principals without
setting environment variables for each process.

> PS. I note that you're affiliated with MIT, so this is probably not your
> fault, and I don't expect you to know the answers to my questions. :-)

Well, I am responsible for implementing similar collection behavior in
MIT krb5 1.10, so you can blame me for that.  (The MIT krb5 kinit
follows slightly different rules for selecting its output ccache.  In
step 1, it only scans the collection if the default cache type supports
switching.  In step 2, if the default ccache hasn't been initialized,
kinit will use that in preference to creating a new one.)