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

[Amos Jeffries]

I've asked Markus our Kerberos developer;

On 1/11/2015 6:24 a.m., Markus Moeller wrote:
> Hi Amos,
>
>   I looked at the patch and it seems fine.   The user just has to know
> when to renew the cache.
>
> Markus
>

I still think we should have a separate auth-no-keytab flag though.
Besides the reasons I outlined earlier (below) it can be used to
document on squid.conf the conditions of use for the flag separate from
NEGOTIATE as a whole.

Can we have an updated patch to audit please?

Amos


On 23/10/2015 4:22 a.m., Amos Jeffries wrote:
> 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
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>