Skip site navigation (1) Skip section navigation (2)

Re: Preliminary GSSAPI Patches

From: "Henry B(dot) Hotz" <hbhotz(at)oxy(dot)edu>
To: Henry B(dot) Hotz <hbhotz(at)oxy(dot)edu>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Preliminary GSSAPI Patches
Date: 2007-10-09 23:51:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
You know, I don't know what I was thinking when I sent this.  My  
apologies for the late correction.

Anyone who has a copy of the "host" keys for a machine can  
manufacture kerberos tickets for the "host" service on that machine  
masquerading as absolutely anyone (including people who don't  
exist).  Same for the "postgres" keys, and if the postgres server can  
steal the host keys (or vice versa) then it's even worse.

I don't know of any exploit code that is designed for this purpose,  
but there is code that uses this property to (legitimately) provide  
kerberos tickets for AFS in scenarios where the KDC can't.

On Jun 24, 2007, at 10:10 PM, Henry B. Hotz wrote:

> On Jun 23, 2007, at 1:44 AM, Magnus Hagander wrote:
>> Stephen Frost wrote:
>>> * Henry B. Hotz (hbhotz(at)oxy(dot)edu) wrote:
>>>> On Jun 22, 2007, at 9:56 AM, Magnus Hagander wrote:
>>>>> Most likely it's just checking the keytab to find a principal  
>>>>> with the
>>>>> same name as the one presented from the client. Since one is
>>>>> present, it
>>>>> loads it up automatically, and verifies against it.
>>>> Bingo!
>>>> The server uses the keytab to decrypt the token provided by the
>>>> client.  By using the GSS_C_NO_CREDENTIAL arg on the server  
>>>> anything
>>>> put in the keytab is OK.  (The server doesn't need to authenticate
>>>> itself to Kerberos, it just accepts authentication.  Mutual
>>>> authentication is done using the same keys.)  The documentation  
>>>> needs
>>>> to reflect that.
>>> I agree there's some disconnect there between the documentation  
>>> and the
>>> apparent implementation but I'm not sure I'm in favor of changing  
>>> the
>>> documentation on this one.  Personally, I'd rather it return an  
>>> error if
>>> someone tries to use GSS_C_NO_CREDENTIAL when accepting a context  
>>> than
>>> to just be happy using anything in the keytab.
>> How about doing both, then? Set the principal name if it's  
>> specified in
>> the config file. If it's explicitly set to an empty string, use
>> GSS_C_NO_CREDENTIAL. Seems straightforward enough to me, and  
>> shouldn't
>> be hard to implement.
> I don't have a problem with that, but you'll want multiple service  
> names as soon as you want to support the SSPI.
> Also don't get too bent out of shape about some client using the  
> wrong service name.  The client *still* needs to prove who it  
> represents;  there's no hole there.  The only real security issue I  
> can think of is that someone who subverts the PostgreSQL server  
> could steal the "host" service keys and then (with a whole bunch of  
> other work) masquerade as the SSH daemon.
>>>> If we do do that, then we need to allow for the ways Microsoft  
>>>> mucks
>>>> with the case of the name.  (Kerberos is supposed to be case
>>>> sensitive, but Microsoft work that way.)  In particular I think we
>>>> may need both postgres/<server> and POSTGRES/<server> in the keytab
>>>> in order to support the to-be-written native Windows SSPI client at
>>>> the same time as the current Kerberos 5 and GSSAPI Unix clients.
>>> Supporting multiple, specific, keys might be an interesting  
>>> challenge,
>>> but I'm not too keen on worrying about it right now regardless.  I'd
>>> also much rather err on the side of "overly paranoid" than "if it  
>>> works,
>>> just let it in".  If someone ends up having to support both  
>>> windows SSPI
>>> clients and unix Kerberos/GSSAPI clients it's entirely possible to
>>> suggest they just make it POSTGRES and configure the clients
>>> accordingly.
>> Yeah, that's how we do it today with Kerberos. But it *would* be  
>> handy
>> if this was easier ;-)
> Don't read too much into the mod_auth_kerb situation.  The main  
> reason it still takes a specific, configured service name is that  
> neither Russ Allbery nor I has gotten around to submitting a proper  
> patch to fix that.  The only reason it was written the way it is in  
> the first place is that the ability to use GSS_C_NO_CREDENTIAL that  
> way is "obscure" and most people don't know it.  I can say that  
> with some confidence because Russ and I had a long discussion with  
> Sam Hartman about how it ought to be done.
> I'm told that the way Apple's equivalent to mod_auth_kerb works is  
> it uses GSS_C_NO_CREDENTIAL and then does a case-insensitive  
> compare of the resulting match to "HTTP".  We could do the same  
> thing, if you think it's worth it.
> ---------------------------------------------------------------------- 
> --
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

In response to


pgsql-patches by date

Next:From: Euler Taveira de OliveiraDate: 2007-10-10 01:38:47
Subject: Re: Provide a way to not ask for a password in psql
Previous:From: Oleg BartunovDate: 2007-10-09 19:02:43
Subject: Re: Preliminary patch for tsearch example dictionaries/parsers in contrib

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group