[squid-dev] [PATCH] add support for using an existing kerberos cache instead of a keytab

[Amos Jeffries]

On 23/10/2015 2:30 a.m., aymericvincent wrote:
> 

> Hi,
> 
> the attached patch adds a NOKEYTAB option to the login=NEGOTIATE case
> (a local proxy needs to authenticate via kerberos to a proxy peer).
> 
> When specified, this option prevents squid from crafting a kerberos
> credentials cache from a keytab, but instead lets GSSAPI use an
> existing credentials cache.
> 
> This is very useful to allow a normal user to use his user
> credentials to run a local unprivileged squid on his desktop/laptop
> without having to deploy a keytab on the (say) parent proxy.
> 
> The way the option is specified is IMHO sub-optimal (sorry) but
> minimises diff footprint, and I'm open to any suggestion if you're
> interested in incorporating this simple yet useful change.
> 

There are two existing Negotiate auth cases.

* One where a "login=NEGOTIATE:principle_name" is given and causes Squid
to load the named entry from the users keytab.

* One where only "login=NEGOTIATE" is given, and causes Squid to load
the default (first) entry from the users default keytab.

In both cases the keytab entry can specify a memory cache contains the
credentials, or a specific named account. But that is stored in the
keytab itself. Not in squid.conf settings.

This patch appears to make Squid ignore loading keytabs entirely and
just allow random credentials from unspecified location(s) to be used.

In the absence of a location from which to load the credentials where
does GSSAPI load the credentials from?

Is the users generic cache backed by a keytab somewhere in the local
account? and why can't we just load that?

Is that GSSAPI behaviour consistent across the four krb5 libraries Squid
can be built to use?


Overall this seems to me to be making Squid pick a random user account
from the machine and sending a lot of traffic through some peer
pretending to be that user instead of a proxy. That is bad security, and
Kerberos is supposed to be the most secure authentication possible. So I
am not happy with this (yet).

Whatever we end up with Squid should never be impersonating a user
account. Ever. It is an automated service, not a person.



NP: don't worry about small diff. We are in feature freeze for Squid-4
beta cycle. Since this is a small UI change it will be held anyway until
Squid-5 branching, which is likely to be a month or two away.

IMO if accepted this should be a separate flag option available on
cache_peer. It would then be a boolean value in the CachePeer object
instead of a global macro #define.

Amos