Patch to ignore service principals when accepting connexions.

[Roland C. Dowdeswell]

On Wed, Aug 25, 2010 at 05:45:17PM -0400, Sam Hartman wrote:
>

> My initial reaction to this patch is negative, particularly to exposing
> an environment variable for this behavior change.

I wasn't particularly fond of the environment variable approach
either.  I came to it as a matter of expedience.  I would like to
roll this patch out at an organisation with over fifty thousand
machines running thousands of Kerberised applications in a relatively
controlled fashion over a long period of time while allowing
individual applications the ability to easily select this behaviour
if it is necessary while not encouraging them to craft their own
krb5.confs and point KRB5_CONFIG at them because that would take
them out of our central management.  Hence the dual approach of
krb5.conf setting to slowly roll it out and the environment variable.

I would not be averse to maintaining the env var locally.

>                                                    In general, if an
> application is going to use GSS_C_NO_CREDENTIAL, it needs to examine the
> service name that was accepted and make an authorization decision.

I do not believe that there is an authorisation decision here at
all in the normal case.  The client needs to ensure that it is
talking to the correct service principal but the server generally
just needs to ensure that it is talking to the correct client.
The service principal that the client selects is an issue of
configuration not of authorisation.  Granted, system admins could
put inappropriate keys in their keytabs but this is not really an
authorisation problem---it is a security problem with their
configuration.

And so, there is little value in an application making this decision
on its own---and in fact, it is actively harmful as it reduces the
control that the system administrator has over his environment.
I have yet to see a single Kerberised application written to be
configurable to pass in a list of service principals to
gss_accept_sec_context() and it is extremely rare for applications
that we see to allow any configurability at all.  Even in cases
where applications do allow this to be configured, the Kerberos
libraries are generally called with GSS_NT_HOSTBASED_SERVICE which
has the unfortunate side effect of doing forward and reverse lookups
on Linux which disagrees with some Kerberos client implementations...

Not to mention the fact that applications calling gss_acquire_creds()
on the server side with GSS_NT_HOSTBASED_SERVICE expose themselves
to an external dependency on nameservice which could be broken at
the time of either application startup, first connexion acceptance
or each connexion acceptance.  I have seen many application servers
written to ``optimise'' by calling gss_acquire_cred() only on
startup which means that you will have to restart the server if
you rename the host or if there was bogus information in DNS/NIS/YP
at startup.  We'd like to get rid of this because we are averse to
requiring server restarts.

> Changing the behavior of applications under the covers seems like it is
> likely to introduce authorization problems.  Yes, you can be very
> careful about what principals you make available, but this still seems
> relatively dangerous.
> 
> However, I do understand the concern.
> 
> We introduced a behavior change in 1.7 so that application no longer
> examine the service name encoded in a ticket; instead, they look at
> whether the key matches.  This means that you can have KDC-side aliases
> either by setting principals to have the same key or by using actual
> aliases (as we support with the LDAP backend).  In that environment, you
> would have one key in your keytab, but the KDC would issue tickets with
> that key for multiple principal names. The KDC configuration is the
> layer at which authorization happens;any name that has the key in the
> service keytab is authorized.

I think that this is aimed at solving a different problem than the
one that we have.

> I think it would be valuable to work through how complicated this would
> be from an administrative standpoint and see if we can make that work to
> meet people's needs.  If we can't then we should closely look at some
> option along the lines you propose.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/