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

[Amos Jeffries]

On 23/10/2015 3:59 a.m., aymericvincent wrote:
> 
> Hi,
> 
> "Amos Jeffries" writes:
> 
>> This patch appears to make Squid ignore loading keytabs entirely and
>> just allow random credentials from unspecified location(s) to be used.
> 
> That's correct and that's the whole point of the diff. ("unspecified location"... to squid)
> 
>> In the absence of a location from which to load the credentials where
>> does GSSAPI load the credentials from?
> 
> When a user is logged in and authenticated to a kdc, a credentials cache is kept around (in practice in a file belonging to the user in /tmp on Unix) and used whenever kerberos authentication is required by a client. That's what you see when you type "klist" for example. Given that one of the interesting features of kerberos is single sign on, I would be surprised that the behaviour is not very similar on other OSes/implementations.
> 
>> Is the users generic cache backed by a keytab somewhere in the local
>> account? and why can't we just load that?
> 
> I'm not familiar enough with kerberos to be authoritative, but I'm quite sure it's not the case : the ticket granting ticket is provided in exchange for the user's password, not thanks to a user-specific keytab AFAIK.
> 
>> 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).
> 
> I'm fine with your opinion, but you should replace "a random user account" by "the account which started squid".

I'm not sure even that is true. Because Squid dynamically alters its
user account for the workers. They may be running as some other
effective user with a different credentials cache.

Which reminds me that Squid usually cannot be started by a non-root user
anyway. There are root privileges required to do effective-user changes,
capabilities assignment, access kernel NAT tables and some other socket
operations we do.

> 
>> 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.
> 
> OK, I'll keep that in mind. So we can devise a better way of specifying the option. Moreover, I also realised that keeping the ability to specify a principal name in the NOKEYTAB case is pointless (and will be ignored by the current code) so if others prefer to keep a similar syntax (I'm not fond of it either), it could be login=NEGOTIATE:NOKEYTAB directly and not login=NEGOTIATE::NOKEYTAB.
> 

 "login=NEGOTIATE auth-no-keytab" should do.

Like I mentioned that allows a simple boolean flag in the CachePeer.
Which avoids the macro define. And also adjusting the if conditions in
all the places auth type is detected by those nasty strcmp/strncmp tests.

Amos