Thread: 8.3 GSS Issues

8.3 GSS Issues

From
"Henry B. Hotz"
Date:
I know I haven't been very active for a while here, but I just got to  
testing the October 3 version a bit prior to getting back to the Java  
GSS client stuff I promised.  There seem to be some funny things there.

The only serious issue is that the server doesn't require the realm  
name to match.  I haven't looked at how that broke yet, but I know I  
was careful of that point in my original patches because it's always  
been wrong in the Kerberos 5 auth method.

If I set up a server I might conceivably get connections from:

smith@JPL.NASA.GOV
smith@STANFORD.EDU
smith@ARC.NASA.GOV
smith@GSFC.NASA.GOV
smith@KSC.NASA.GOV
<same for every other NASA center, HQ, plus a "fake" realm relating  
to how NASA set up AD>

Now the only two of those that *might* be the same person are the  
first two, and that's only if the Stanford person has a grant to work  
on a JPL project and got put in our infrastructure as an affiliate,  
*and* the username wasn't already taken.

It appears that you can just put a complete (realm-included) name  
into postgres, so that's obviously the way to support gssapi  
connections from non-default realms.

In short this is a security hole.  IMO it should be fixed prior to  
release.

---------

I notice there are hba options for gss and sspi both.  Why?

Is there some windows-only functionality it enables?  Shouldn't we be  
using Microsoft's advertised GSSAPI/SSPI compatibility?  If you build  
on Windows then I'm sure you want to link the SSPI libraries rather  
than require installation of a separate package, but that shouldn't  
change the functionality or the wire protocol AFAIK.  In other words  
I would expect this to be a build-time option.

---------

At the risk of diluting my message:  I still think it's a mistake to  
call it gss instead of something like gss-noprot.  I believe this  
will cause misunderstandings in the future when we get the security  
layer of gssapi implemented.

---------

There's no way to specify the gssapi library to use.  I have three on  
my main development Sun:  MIT, Sun, and Heimdal.  I might have more  
than one version of one of those three at some times.  Of course  
there's no way to specify which kerberos 5 library or openssl library  
you want either, so consider this a feature request for future  
development.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




Re: 8.3 GSS Issues

From
Bruce Momjian
Date:
Patch applied.  Thanks.

---------------------------------------------------------------------------


Henry B. Hotz wrote:
> I know I haven't been very active for a while here, but I just got to  
> testing the October 3 version a bit prior to getting back to the Java  
> GSS client stuff I promised.  There seem to be some funny things there.
> 
> The only serious issue is that the server doesn't require the realm  
> name to match.  I haven't looked at how that broke yet, but I know I  
> was careful of that point in my original patches because it's always  
> been wrong in the Kerberos 5 auth method.
> 
> If I set up a server I might conceivably get connections from:
> 
> smith@JPL.NASA.GOV
> smith@STANFORD.EDU
> smith@ARC.NASA.GOV
> smith@GSFC.NASA.GOV
> smith@KSC.NASA.GOV
> <same for every other NASA center, HQ, plus a "fake" realm relating  
> to how NASA set up AD>
> 
> Now the only two of those that *might* be the same person are the  
> first two, and that's only if the Stanford person has a grant to work  
> on a JPL project and got put in our infrastructure as an affiliate,  
> *and* the username wasn't already taken.
> 
> It appears that you can just put a complete (realm-included) name  
> into postgres, so that's obviously the way to support gssapi  
> connections from non-default realms.
> 
> In short this is a security hole.  IMO it should be fixed prior to  
> release.
> 
> ---------
> 
> I notice there are hba options for gss and sspi both.  Why?
> 
> Is there some windows-only functionality it enables?  Shouldn't we be  
> using Microsoft's advertised GSSAPI/SSPI compatibility?  If you build  
> on Windows then I'm sure you want to link the SSPI libraries rather  
> than require installation of a separate package, but that shouldn't  
> change the functionality or the wire protocol AFAIK.  In other words  
> I would expect this to be a build-time option.
> 
> ---------
> 
> At the risk of diluting my message:  I still think it's a mistake to  
> call it gss instead of something like gss-noprot.  I believe this  
> will cause misunderstandings in the future when we get the security  
> layer of gssapi implemented.
> 
> ---------
> 
> There's no way to specify the gssapi library to use.  I have three on  
> my main development Sun:  MIT, Sun, and Heimdal.  I might have more  
> than one version of one of those three at some times.  Of course  
> there's no way to specify which kerberos 5 library or openssl library  
> you want either, so consider this a feature request for future  
> development.
> 
> ------------------------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: 8.3 GSS Issues

From
Bruce Momjian
Date:
Sorry, wrong email.  Nothing applied.

---------------------------------------------------------------------------

Henry B. Hotz wrote:
> I know I haven't been very active for a while here, but I just got to  
> testing the October 3 version a bit prior to getting back to the Java  
> GSS client stuff I promised.  There seem to be some funny things there.
> 
> The only serious issue is that the server doesn't require the realm  
> name to match.  I haven't looked at how that broke yet, but I know I  
> was careful of that point in my original patches because it's always  
> been wrong in the Kerberos 5 auth method.
> 
> If I set up a server I might conceivably get connections from:
> 
> smith@JPL.NASA.GOV
> smith@STANFORD.EDU
> smith@ARC.NASA.GOV
> smith@GSFC.NASA.GOV
> smith@KSC.NASA.GOV
> <same for every other NASA center, HQ, plus a "fake" realm relating  
> to how NASA set up AD>
> 
> Now the only two of those that *might* be the same person are the  
> first two, and that's only if the Stanford person has a grant to work  
> on a JPL project and got put in our infrastructure as an affiliate,  
> *and* the username wasn't already taken.
> 
> It appears that you can just put a complete (realm-included) name  
> into postgres, so that's obviously the way to support gssapi  
> connections from non-default realms.
> 
> In short this is a security hole.  IMO it should be fixed prior to  
> release.
> 
> ---------
> 
> I notice there are hba options for gss and sspi both.  Why?
> 
> Is there some windows-only functionality it enables?  Shouldn't we be  
> using Microsoft's advertised GSSAPI/SSPI compatibility?  If you build  
> on Windows then I'm sure you want to link the SSPI libraries rather  
> than require installation of a separate package, but that shouldn't  
> change the functionality or the wire protocol AFAIK.  In other words  
> I would expect this to be a build-time option.
> 
> ---------
> 
> At the risk of diluting my message:  I still think it's a mistake to  
> call it gss instead of something like gss-noprot.  I believe this  
> will cause misunderstandings in the future when we get the security  
> layer of gssapi implemented.
> 
> ---------
> 
> There's no way to specify the gssapi library to use.  I have three on  
> my main development Sun:  MIT, Sun, and Heimdal.  I might have more  
> than one version of one of those three at some times.  Of course  
> there's no way to specify which kerberos 5 library or openssl library  
> you want either, so consider this a feature request for future  
> development.
> 
> ------------------------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: 8.3 GSS Issues

From
Magnus Hagander
Date:
On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
> I know I haven't been very active for a while here, but I just got to  
> testing the October 3 version a bit prior to getting back to the Java  
> GSS client stuff I promised.  There seem to be some funny things there.

Apologies for not responding to this one sooner.

BTW, what's the status on the Java stuff? Will it be around by the time 8.3
is released?


> The only serious issue is that the server doesn't require the realm  
> name to match.  I haven't looked at how that broke yet, but I know I  
> was careful of that point in my original patches because it's always  
> been wrong in the Kerberos 5 auth method.

I honestly don't remember exactly how that became. I think I stripped it
out in order to make it work like the krb5 method.

What you're asking for is basically a krb_match_realm parameter, or do I
understand you wrong?


> It appears that you can just put a complete (realm-included) name  
> into postgres, so that's obviously the way to support gssapi  
> connections from non-default realms.
> 
> In short this is a security hole.  IMO it should be fixed prior to  
> release.

Can't you also configure the kerberos libraries on your machine not to
accept other realms than your own? IIRC, that was something considered at
the time, but I can't find a reference to such a discussion.


> ---------
> 
> I notice there are hba options for gss and sspi both.  Why?
> 
> Is there some windows-only functionality it enables?  Shouldn't we be  
> using Microsoft's advertised GSSAPI/SSPI compatibility?  If you build  
> on Windows then I'm sure you want to link the SSPI libraries rather  
> than require installation of a separate package, but that shouldn't  
> change the functionality or the wire protocol AFAIK.  In other words  
> I would expect this to be a build-time option.

There was discussion about this, and we were presented with clear cases
where you'd want to be able to do either one. Making it a build option
doesn't help the 99.9% of Windows users that use a pre-packaged binary
distribution.

> ---------
> 
> At the risk of diluting my message:  I still think it's a mistake to  
> call it gss instead of something like gss-noprot.  I believe this  
> will cause misunderstandings in the future when we get the security  
> layer of gssapi implemented.

Well, I don't agree with this, but if others want it changed, it can
certainly be changed. And it can only be changed *now*, and not once we
release.

But we have "host" and "hostssl", not "hostnossl" and "host". So the way we
are donig it now is IMO more consistent with what we have in other parts of pg.

> ---------
> 
> There's no way to specify the gssapi library to use.  I have three on  
> my main development Sun:  MIT, Sun, and Heimdal.  I might have more  
> than one version of one of those three at some times.  Of course  
> there's no way to specify which kerberos 5 library or openssl library  
> you want either, so consider this a feature request for future  
> development.

Yeah, that's something that can be done for 8.4, certainly not something we
can put in now. But I'll be happy to see a patch once we open the tree for
8.4 :-)

//Magnus


Re: 8.3 GSS Issues

From
Alvaro Herrera
Date:
Magnus Hagander wrote:
> On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:

> > At the risk of diluting my message:  I still think it's a mistake to  
> > call it gss instead of something like gss-noprot.  I believe this  
> > will cause misunderstandings in the future when we get the security  
> > layer of gssapi implemented.
> 
> Well, I don't agree with this, but if others want it changed, it can
> certainly be changed. And it can only be changed *now*, and not once we
> release.
> 
> But we have "host" and "hostssl", not "hostnossl" and "host". So the way we
> are donig it now is IMO more consistent with what we have in other parts of pg.

Actually we have "hostssl", "hostnossl" and "host".

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


Re: 8.3 GSS Issues

From
Magnus Hagander
Date:
On Thu, Oct 25, 2007 at 09:26:47AM -0300, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
> 
> > > At the risk of diluting my message:  I still think it's a mistake to  
> > > call it gss instead of something like gss-noprot.  I believe this  
> > > will cause misunderstandings in the future when we get the security  
> > > layer of gssapi implemented.
> > 
> > Well, I don't agree with this, but if others want it changed, it can
> > certainly be changed. And it can only be changed *now*, and not once we
> > release.
> > 
> > But we have "host" and "hostssl", not "hostnossl" and "host". So the way we
> > are donig it now is IMO more consistent with what we have in other parts of pg.
> 
> Actually we have "hostssl", "hostnossl" and "host".

Good point. But the line that corresponds to what is currently called "gss"
is "host" :)

//Magnus


Re: 8.3 GSS Issues

From
Tom Lane
Date:
Magnus Hagander <magnus@hagander.net> writes:
> On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
>> There's no way to specify the gssapi library to use.  I have three on  
>> my main development Sun:  MIT, Sun, and Heimdal.  I might have more  
>> than one version of one of those three at some times.  Of course  
>> there's no way to specify which kerberos 5 library or openssl library  
>> you want either, so consider this a feature request for future  
>> development.

> Yeah, that's something that can be done for 8.4, certainly not something we
> can put in now. But I'll be happy to see a patch once we open the tree for
> 8.4 :-)

Isn't this something you do by specifying include and link search paths
to configure?  The above argument could be made for *any* library we
use, and I surely do not want to put a single-purpose switch for each
library into configure.
        regards, tom lane


Re: 8.3 GSS Issues

From
"Henry B. Hotz"
Date:
On Oct 25, 2007, at 10:22 AM, Tom Lane wrote:

> Magnus Hagander <magnus@hagander.net> writes:
>> On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
>>> There's no way to specify the gssapi library to use.  I have  
>>> three on
>>> my main development Sun:  MIT, Sun, and Heimdal.  I might have more
>>> than one version of one of those three at some times.  Of course
>>> there's no way to specify which kerberos 5 library or openssl  
>>> library
>>> you want either, so consider this a feature request for future
>>> development.
>
>> Yeah, that's something that can be done for 8.4, certainly not  
>> something we
>> can put in now. But I'll be happy to see a patch once we open the  
>> tree for
>> 8.4 :-)
>
> Isn't this something you do by specifying include and link search  
> paths
> to configure?  The above argument could be made for *any* library we
> use, and I surely do not want to put a single-purpose switch for each
> library into configure.

All the other OS packages I've looked at seem to support a per- 
support-option specification of the relevant installation to use for  
that support.  I expect that's a pain to implement, but it's what I  
(and presumably other people) expect.

As I said this is a request for the future.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




Re: 8.3 GSS Issues

From
"Henry B. Hotz"
Date:
On Oct 25, 2007, at 1:47 AM, Magnus Hagander wrote:

> On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote:
>> I know I haven't been very active for a while here, but I just got to
>> testing the October 3 version a bit prior to getting back to the Java
>> GSS client stuff I promised.  There seem to be some funny things  
>> there.
>
> Apologies for not responding to this one sooner.
>
> BTW, what's the status on the Java stuff? Will it be around by the  
> time 8.3
> is released?

Touche.  ;-)  I hope to get to that in the next couple of weeks.

>> The only serious issue is that the server doesn't require the realm
>> name to match.  I haven't looked at how that broke yet, but I know I
>> was careful of that point in my original patches because it's always
>> been wrong in the Kerberos 5 auth method.
>
> I honestly don't remember exactly how that became. I think I  
> stripped it
> out in order to make it work like the krb5 method.

What the krb5 method does is IMO a documented bug.  The realm name is  
part of the name.

As I explained at some length you cannot assume the username (first  
component of the principal) has any meaning by itself, except in  
small deployments with no external trust agreements.  Kerberos (and  
AD) are designed to support larger infrastructures with multiple  
organizations.

> What you're asking for is basically a krb_match_realm parameter, or  
> do I
> understand you wrong?

I'm asking for name matching to be done i.a.w. the gssapi  
recommendations.  That's "all" I want, but it's actually necessary  
for this feature to be at all usable in my environment.  If we don't  
then I suggest we pull this feature until it can be done correctly.

If you want to add a non-default ignore_realm option I have no  
objection, but the code may not be robust to varying gssapi  
implementations.  Guaranteed it won't work with a non-kerberos  
mechanism like SPKM (which isn't widely deployed).

For a proper discussion of this topic I recommend the section  
starting on page 64 of Sun's Security for Developers Guide, document  
816-4863.  Note that there is a discussion of how to do compares  
efficiently.  IIRC my patch did things the "easy" way described on  
page 67.  In the long run it's possible we'd want to do it the "fast"  
way described on page 69, but that's merely an optimization and might  
not be needed.

>> It appears that you can just put a complete (realm-included) name
>> into postgres, so that's obviously the way to support gssapi
>> connections from non-default realms.
>>
>> In short this is a security hole.  IMO it should be fixed prior to
>> release.
>
> Can't you also configure the kerberos libraries on your machine not to
> accept other realms than your own? IIRC, that was something  
> considered at
> the time, but I can't find a reference to such a discussion.

Kerberos is about authenticating (identifying) users, not determining  
what they're authorized (allowed) to do.

At the basic protocol level I can only refuse to exchange cross-realm  
keys with anybody.  There's a NASA interpretation of a Presidential  
directive that would likely prohibit me from using this option, even  
if I wanted to.  If I have even one user @NASA.GOV that I want to  
allow in to even one service @JPL.NASA.GOV then I can't use this option.

The three major Kerberos implementations, Microsoft, MIT (including  
Apple and Sun), and Heimdal, all have different degrees of support  
for authorization control.

MIT and Heimdal (and Microsoft, I assume) will let you trust  
STANFORD.EDU and *.NASA.GOV without (for example) trusting  
STANFORD.EDU to identify smith@ARC.NASA.GOV.

Microsoft bundles their Kerberos with an LDAP server so they can do  
fine-grained authorization control from the same place.  Every  
individual user in any trusted realm needs to have an entry in the  
local LDAP in order to get access to a Windows service.

MIT supports an "auth_to_local" translation service to relate  
Kerberos principals to local workstation usernames.  By default, the  
local realm is translated to the username by stripping the realm  
name.  Other realms do not translate.  The facility is poorly  
documented, and not standard, so I cannot recommend it.

>> ---------
>>
>> I notice there are hba options for gss and sspi both.  Why?
>>
>> Is there some windows-only functionality it enables?  Shouldn't we be
>> using Microsoft's advertised GSSAPI/SSPI compatibility?  If you build
>> on Windows then I'm sure you want to link the SSPI libraries rather
>> than require installation of a separate package, but that shouldn't
>> change the functionality or the wire protocol AFAIK.  In other words
>> I would expect this to be a build-time option.
>
> There was discussion about this, and we were presented with clear  
> cases
> where you'd want to be able to do either one. Making it a build option
> doesn't help the 99.9% of Windows users that use a pre-packaged binary
> distribution.

Doesn't exactly answer my question, but I guess there exists a  
Windows use case where linking against a non-SSPI support library is  
needed.  (I actually have such a use case, but I'd consider it a  
transient problem due to a bad deployment.)  This puts you into the  
deployment model that Firefox uses, where there's a config option for  
which support library you use.  Sounds messy, and I feel sorry for  
the people who have to support it.

>> ---------
>>
>> At the risk of diluting my message:  I still think it's a mistake to
>> call it gss instead of something like gss-noprot.  I believe this
>> will cause misunderstandings in the future when we get the security
>> layer of gssapi implemented.
>
> Well, I don't agree with this, but if others want it changed, it can
> certainly be changed. And it can only be changed *now*, and not  
> once we
> release.
>
> But we have "host" and "hostssl", not "hostnossl" and "host". So  
> the way we
> are donig it now is IMO more consistent with what we have in other  
> parts of pg.

Sorry, I don't follow how that's comparable, unless you're proposing  
a "hostgss" option for the future?  We can agree to disagree on this  
point, but. . .

GSSAPI includes session encryption.  I couldn't figure out how to fit  
that into PG's buffering model, so I supplied a stripped down patch  
that omitted that capability.  (After all the current krb5 method  
omitted the capability as well.)  I don't think we should pretend  
that what we're delivering now is the full, standard capability.   
It's not best practice.


I hope I don't sound like I'm whining here.  I do appreciate the  
support you've given me.  I still want to deliver what I promised.   
I'm sorry that that JPL project decided to go with MySQL instead, but  
that affects the priority I can give this work.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




Re: 8.3 GSS Issues

From
Stephen Frost
Date:
* Henry B. Hotz (hotz@jpl.nasa.gov) wrote:
> What the krb5 method does is IMO a documented bug.  The realm name is part
> of the name.
>
> As I explained at some length you cannot assume the username (first
> component of the principal) has any meaning by itself, except in small
> deployments with no external trust agreements.  Kerberos (and AD) are
> designed to support larger infrastructures with multiple organizations.

This isn't unexpected for PG as the current krb5 support does this.  I'm
not a big fan of it but at the same time I don't feel it's justification
to drop it from 8.3.  Having it only allow the default realm would be an
option which could work in 8.3, imv.  Longer term (since it's likely too
late to be accepted now), as I think has been discussed in the past, PG
could really use a .k5login-esque, either admin-only (ala pg_hba.conf /
ident map) or per-user (some sort of ALTER ROLE that a user could do on
himself?), mapping functionality.

It doesn't strike me as terribly complex or hard to do but it certainly
goes beyond the what is currently implemented for GSS in 8.3, and what
exists currently for krb5.  It's also something which could,
technically, be added later.  I do think it would be better done now
though, if possible, since otherwise we would have to default to the
current sub-par behaviour for quite some time (if not forever).
Thanks,
    Stephen

Re: 8.3 GSS Issues

From
"Henry B. Hotz"
Date:
On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:

> * Henry B. Hotz (hotz@jpl.nasa.gov) wrote:
>> What the krb5 method does is IMO a documented bug.  The realm name  
>> is part
>> of the name.
>>
>> As I explained at some length you cannot assume the username (first
>> component of the principal) has any meaning by itself, except in  
>> small
>> deployments with no external trust agreements.  Kerberos (and AD) are
>> designed to support larger infrastructures with multiple  
>> organizations.
>
> This isn't unexpected for PG as the current krb5 support does  
> this.  I'm
> not a big fan of it but at the same time I don't feel it's  
> justification
> to drop it from 8.3.  Having it only allow the default realm would  
> be an
> option which could work in 8.3, imv.

I don't think the fact that the existing krb5 code does the wrong  
thing (and can't be used in an environment with cross-realm  
agreements) is justification for doing the wrong thing in a new  
capability.  The code in my original patch would do the latter  
(default realm only).

More precisely:  if you do a gss_import_name() on "smith" and  
"smith@DEFAULT.REALM" you get the same internal representation, and  
gss_compare_name() will tell you they're the same.  Also  
gss_compare_name() will tell you "smith@OTHER.REALM" is different  
from either of the first two.

If we don't use gss_compare_name(), or some similar mechanism, to  
compare connection names to PG usernames, then I don't think GSSAPI  
support should be included in 8.3.

> Longer term (since it's likely too
> late to be accepted now), as I think has been discussed in the  
> past, PG
> could really use a .k5login-esque, either admin-only (ala  
> pg_hba.conf /
> ident map) or per-user (some sort of ALTER ROLE that a user could  
> do on
> himself?), mapping functionality.

There has been discussion of a general mapping layer between  
authentication names and authorization/role names.  I think that's  
the way to go.  I haven't thought about who or where the  
administration of the mapping ought to be.

See note about authentication vs authorization in last email.

> It doesn't strike me as terribly complex or hard to do but it  
> certainly
> goes beyond the what is currently implemented for GSS in 8.3, and what
> exists currently for krb5.  It's also something which could,
> technically, be added later.  I do think it would be better done now
> though, if possible, since otherwise we would have to default to the
> current sub-par behaviour for quite some time (if not forever).
>
>     Thanks,
>
>         Stephen

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




Re: 8.3 GSS Issues

From
Magnus Hagander
Date:
On Thu, Oct 25, 2007 at 05:39:37PM -0700, Henry B. Hotz wrote:
> 
> On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:
> 
> >* Henry B. Hotz (hotz@jpl.nasa.gov) wrote:

> >What you're asking for is basically a krb_match_realm parameter, or
> >do I
> >understand you wrong?
>
> I'm asking for name matching to be done i.a.w. the gssapi
> recommendations.  That's "all" I want, but it's actually necessary
> for this feature to be at all usable in my environment.  If we don't
> then I suggest we pull this feature until it can be done correctly.

I know what you want, that's fairly obvious. I'm only asking about *how* to
do it the best way.


> >>What the krb5 method does is IMO a documented bug.  The realm name  
> >>is part
> >>of the name.
> >>
> >>As I explained at some length you cannot assume the username (first
> >>component of the principal) has any meaning by itself, except in  
> >>small
> >>deployments with no external trust agreements.  Kerberos (and AD) are
> >>designed to support larger infrastructures with multiple  
> >>organizations.
> >
> >This isn't unexpected for PG as the current krb5 support does  
> >this.  I'm
> >not a big fan of it but at the same time I don't feel it's  
> >justification
> >to drop it from 8.3.  Having it only allow the default realm would  
> >be an
> >option which could work in 8.3, imv.
> 
> I don't think the fact that the existing krb5 code does the wrong  
> thing (and can't be used in an environment with cross-realm  
> agreements) is justification for doing the wrong thing in a new  
> capability.  The code in my original patch would do the latter  
> (default realm only).
> 
> More precisely:  if you do a gss_import_name() on "smith" and  
> "smith@DEFAULT.REALM" you get the same internal representation, and  
> gss_compare_name() will tell you they're the same.  Also  
> gss_compare_name() will tell you "smith@OTHER.REALM" is different  
> from either of the first two.

Wouldn't using a specific parameter like krb_match_realm=YOUR.REALM that
you set in the config file be more flexible? In that it actually allows
scenarios like server/resource domains (not sure how common they are in
unix krb setups, but they're certainly not unfamiliar in the Windows AD
world)?

> If we don't use gss_compare_name(), or some similar mechanism, to  
> compare connection names to PG usernames, then I don't think GSSAPI  
> support should be included in 8.3.

I think that's a horrible idea, given that it works perfectly fine the way
it is now for the vast majority of users.

That said, we should certainly fix it in one way or another for 8.3. But if
that fails, I see no reason at all to pull the feature.

> >Longer term (since it's likely too
> >late to be accepted now), as I think has been discussed in the  
> >past, PG
> >could really use a .k5login-esque, either admin-only (ala  
> >pg_hba.conf /
> >ident map) or per-user (some sort of ALTER ROLE that a user could  
> >do on
> >himself?), mapping functionality.
> 
> There has been discussion of a general mapping layer between  
> authentication names and authorization/role names.  I think that's  
> the way to go.  I haven't thought about who or where the  
> administration of the mapping ought to be.

Yeah, I agree that something like that would be a good long-term solution.

> For a proper discussion of this topic I recommend the section
> starting on page 64 of Sun's Security for Developers Guide, document
> 816-4863.  Note that there is a discussion of how to do compares
> efficiently.  IIRC my patch did things the "easy" way described on
> page 67.  In the long run it's possible we'd want to do it the "fast"
> way described on page 69, but that's merely an optimization and might
> not be needed.

Do you have an URL for this? Or is it a book one has t buy?

//Magnus


Re: 8.3 GSS Issues

From
"Henry B. Hotz"
Date:
On Oct 26, 2007, at 12:56 AM, Magnus Hagander wrote:

> On Thu, Oct 25, 2007 at 05:39:37PM -0700, Henry B. Hotz wrote:
>>
>> On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:
>>
>>> * Henry B. Hotz (hotz@jpl.nasa.gov) wrote:
>
>>> What you're asking for is basically a krb_match_realm parameter,  
>>> or do I understand you wrong?
>>
>> I'm asking for name matching to be done i.a.w. the gssapi
>> recommendations.  That's "all" I want, but it's actually necessary
>> for this feature to be at all usable in my environment.  If we don't
>> then I suggest we pull this feature until it can be done correctly.
>
> I know what you want, that's fairly obvious. I'm only asking about  
> *how* to
> do it the best way.
>
>
>>>> What the krb5 method does is IMO a documented bug.  The realm  
>>>> name is part of the name.
>>>>
>>>> As I explained at some length you cannot assume the username  
>>>> (first component of the principal) has any meaning by itself,  
>>>> except in small deployments with no external trust agreements.   
>>>> Kerberos (and AD) are designed to support larger infrastructures  
>>>> with multiple organizations.
>>>
>>> This isn't unexpected for PG as the current krb5 support does  
>>> this.  I'm not a big fan of it but at the same time I don't feel  
>>> it's justification to drop it from 8.3.  Having it only allow the  
>>> default realm would be an option which could work in 8.3, imv.
>>
>> I don't think the fact that the existing krb5 code does the wrong
>> thing (and can't be used in an environment with cross-realm
>> agreements) is justification for doing the wrong thing in a new
>> capability.  The code in my original patch would do the latter
>> (default realm only).
>>
>> More precisely:  if you do a gss_import_name() on "smith" and
>> "smith@DEFAULT.REALM" you get the same internal representation, and
>> gss_compare_name() will tell you they're the same.  Also
>> gss_compare_name() will tell you "smith@OTHER.REALM" is different
>> from either of the first two.
>
> Wouldn't using a specific parameter like krb_match_realm=YOUR.REALM  
> that
> you set in the config file be more flexible? In that it actually  
> allows
> scenarios like server/resource domains (not sure how common they  
> are in
> unix krb setups, but they're certainly not unfamiliar in the  
> Windows AD
> world)?

Yes and no.  It certainly would have made it easier to test my  
original patch since the server was in a test realm and I couldn't  
use my normal production identity.  I'd imagine deployments where the  
users are in a different realm from the servers are somewhat common.

The counter is that (if done naively) it would prevent you from  
supporting users from multiple realms at all.  I never completely  
tested this, but I think with my original patch you could define both  
"smith" (== "smith@DEFAULT.REALM") and "smith@OTHER.REALM" as users  
to PG.  They wouldn't be the same user (which you might want), but  
you could support both of them.

Is there any (other) code in PG that would barf on long usernames  
that contain "@" and/or "."?

>> If we don't use gss_compare_name(), or some similar mechanism, to
>> compare connection names to PG usernames, then I don't think GSSAPI
>> support should be included in 8.3.
>
> I think that's a horrible idea, given that it works perfectly fine  
> the way
> it is now for the vast majority of users.
>
> That said, we should certainly fix it in one way or another for  
> 8.3. But if
> that fails, I see no reason at all to pull the feature.

If this isn't fixed then PG will never be a supported infrastructure  
service at JPL the way MySQL currently is.  I had hoped to use the  
GSSAPI support as a feature to pry some people away from MySQL, but  
without the ability to integrate into a multi-realm infrastructure  
this won't fly.  Of course even with proper support it still may  
never happen, so that isn't a threat.

>>> Longer term (since it's likely too late to be accepted now), as I  
>>> think has been discussed in the past, PG could really use  
>>> a .k5login-esque, either admin-only (ala pg_hba.conf / ident map)  
>>> or per-user (some sort of ALTER ROLE that a user could do on  
>>> himself?), mapping functionality.
>>
>> There has been discussion of a general mapping layer between
>> authentication names and authorization/role names.  I think that's
>> the way to go.  I haven't thought about who or where the
>> administration of the mapping ought to be.
>
> Yeah, I agree that something like that would be a good long-term  
> solution.

For those on the periphery: the PG protocol already carries the PG  
username, and the Kerberos and GSSAPI auth methods carry the  
authentication name.  If you define the PG username to be the  
authorization name then you have a pretty standard architecture.

If anyone has used a kerberized ssh then you have a similar split.   
You can kinit as "A" and then "ssh B@server".  If you have put "A"  
into ~B/.k5login then you get in without a password prompt.

>> For a proper discussion of this topic I recommend the section
>> starting on page 64 of Sun's Security for Developers Guide, document
>> 816-4863.  Note that there is a discussion of how to do compares
>> efficiently.  IIRC my patch did things the "easy" way described on
>> page 67.  In the long run it's possible we'd want to do it the "fast"
>> way described on page 69, but that's merely an optimization and might
>> not be needed.
>
> Do you have an URL for this? Or is it a book one has to buy?

Sorry.  For the non-Solaris users out there, all their documentation  
is available at http://docs.sun.com/.

Rather than drilling down through their web site it's easier to just  
Google for what you want.  I see that if you just put in the doc  
number you get links for purchasing the book and reporting bugs in  
it, and downloading the examples, but not what you want.  If you  
Google for 816-4863.pdf you get directly to it though.  No doubt  
there are other variations that would work, and if you looked on  
following pages of the first search you ought to find it there too.

One of the problems with discussing Google search terms on open lists  
like this is that if you want to use the same search terms later you  
wind up getting your own emails instead of what you really want.  |-P

Don't sweat the document too much.  It's a bit neurotic in its  
explanations.  Once you have the general idea the Sun man pages (also  
on docs.sun.com) are more useful.  The two referenced outlines  
reflect what's recommended by the RFC's.  AFAIK Sun has the best  
documentation outside of the RFC's.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




Re: 8.3 GSS Issues

From
Magnus Hagander
Date:
Henry B. Hotz wrote:
>>>>> What the krb5 method does is IMO a documented bug.  The realm name
>>>>> is part of the name.
>>>>>
>>>>> As I explained at some length you cannot assume the username (first
>>>>> component of the principal) has any meaning by itself, except in
>>>>> small deployments with no external trust agreements.  Kerberos (and
>>>>> AD) are designed to support larger infrastructures with multiple
>>>>> organizations.
>>>>
>>>> This isn't unexpected for PG as the current krb5 support does this. 
>>>> I'm not a big fan of it but at the same time I don't feel it's
>>>> justification to drop it from 8.3.  Having it only allow the default
>>>> realm would be an option which could work in 8.3, imv.
>>>
>>> I don't think the fact that the existing krb5 code does the wrong
>>> thing (and can't be used in an environment with cross-realm
>>> agreements) is justification for doing the wrong thing in a new
>>> capability.  The code in my original patch would do the latter
>>> (default realm only).
>>>
>>> More precisely:  if you do a gss_import_name() on "smith" and
>>> "smith@DEFAULT.REALM" you get the same internal representation, and
>>> gss_compare_name() will tell you they're the same.  Also
>>> gss_compare_name() will tell you "smith@OTHER.REALM" is different
>>> from either of the first two.
>>
>> Wouldn't using a specific parameter like krb_match_realm=YOUR.REALM that
>> you set in the config file be more flexible? In that it actually allows
>> scenarios like server/resource domains (not sure how common they are in
>> unix krb setups, but they're certainly not unfamiliar in the Windows AD
>> world)?
> 
> Yes and no.  It certainly would have made it easier to test my original
> patch since the server was in a test realm and I couldn't use my normal
> production identity.  I'd imagine deployments where the users are in a
> different realm from the servers are somewhat common.

Yes, that is the "resource domain" model that at least MS suggested you
use earlier on - they may still do so.


> The counter is that (if done naively) it would prevent you from
> supporting users from multiple realms at all.  I never completely tested
> this, but I think with my original patch you could define both "smith"
> (== "smith@DEFAULT.REALM") and "smith@OTHER.REALM" as users to PG.  They
> wouldn't be the same user (which you might want), but you could support
> both of them.

Well, you could turn it off, and use those usernames then, no?


> Is there any (other) code in PG that would barf on long usernames that
> contain "@" and/or "."?

I don't think there is any risk with it containing that, but there is a
max length of a username somewhere of course...


>>> If we don't use gss_compare_name(), or some similar mechanism, to
>>> compare connection names to PG usernames, then I don't think GSSAPI
>>> support should be included in 8.3.
>>
>> I think that's a horrible idea, given that it works perfectly fine the
>> way
>> it is now for the vast majority of users.
>>
>> That said, we should certainly fix it in one way or another for 8.3.
>> But if
>> that fails, I see no reason at all to pull the feature.
> 
> If this isn't fixed then PG will never be a supported infrastructure
> service at JPL the way MySQL currently is.  I had hoped to use the
> GSSAPI support as a feature to pry some people away from MySQL, but
> without the ability to integrate into a multi-realm infrastructure this
> won't fly.  Of course even with proper support it still may never
> happen, so that isn't a threat.

Sure, but that's no reason to pull it from 8.3 if it can only be fixed
in 8.4. It's a good reason to work towards having it fixed in 8.3,
certainly, but not a reason to pull it if it isn't there.

FWIW, I'm fairly certain I can have a match_realm parameter done for beta3.

//Magnus



Re: 8.3 GSS Issues

From
"Henry B. Hotz"
Date:
On Oct 27, 2007, at 1:36 AM, Magnus Hagander wrote:

>> If this isn't fixed then PG will never be a supported infrastructure
>> service at JPL the way MySQL currently is.  I had hoped to use the
>> GSSAPI support as a feature to pry some people away from MySQL, but
>> without the ability to integrate into a multi-realm infrastructure  
>> this
>> won't fly.  Of course even with proper support it still may never
>> happen, so that isn't a threat.
>
> Sure, but that's no reason to pull it from 8.3 if it can only be fixed
> in 8.4. It's a good reason to work towards having it fixed in 8.3,
> certainly, but not a reason to pull it if it isn't there.
>
> FWIW, I'm fairly certain I can have a match_realm parameter done  
> for beta3.

A brief inspection suggests the relevant code from my original patch  
would work with very little modification.  It supports what I need to  
support.

*I* have no need for a "match_realm" parameter as long as realm  
matching *is* done and can be done on a per-user basis.  Obviously it  
would be convenient for some other people if realm matching could be  
disabled or a non-default realm could be made the default and  
required.  I just don't want such "extras" to create security holes  
(by equating different users) or prevent support of the full user pool.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu