Re: [Patch] Subversion 1.5 SASL doesn't work correctly with Kerberos cross-realm authentication

On 2009-07-23 15:30, Lieven Govaerts wrote:
> On Sat, Mar 21, 2009 at 3:06 AM, Alec
> Kloss<alec-dated-1238029604.c45de2_at_setfilepointer.com> wrote:
[chop]
> >
> > Please see attached patch.  It works against 1.6.0 and trunk r36738.
>
> > [[[
> >
> > Add option cross-realm support to cyrus_auth.c. Adds three
> > boolean configuration entries in the [sasl] section:
> >
> > enable-cross-realm: set to enable cross-realm support
> > remove-local-realm: set to true to remove the local realm
> > from a user name, false to keep the realm on a local user.
> > Defaults to !enable-cross-realm
> > remove-remote-realm: set to true to remove the realm of a remote
> > user. This is a potential security hazard and should not
> > be enabled unless you're confident all realms are trustworthy.
> >
> > ]]]
>
> Why do we need those three flags exactly? Can we not select a safe default?
>
> We don't seem to need them for kerberos over http (ra_neon)?
>
> Lieven
>

Short story:

I think that these options are necessary for svnserve to stay
consistent with its current behavior *and* allow it to be
configured the way an administrator in a cross-realm environment
would want it.

Long story:

The safe default is to enable cross realm and never strip the realm
name. Unfortunately, the current implementation disables cross
realm and always strips the realm. If you enable cross-realm by
default and start including the realm, you break everyone's
existing authz files. If you enable cross-realm and still strip
the realm, you're created a potential security problem. If you
stop stripping the realm, everyone's authz files will break when
users start showing up with @REALM on them. I felt the flags and
their defaults were closest to what an administrator would want for
the following reasons:

1. Administrators of simple configurations don't have to worry
about any of this cross-realm stuff.

2. Administrators who need cross-realm can flip a single knob,
enable-cross-realm to make cross-realm work the way they'd expect.

3. Administrators who are migrating from a single realm to multiple
realms can set enable-cross-realm and remove-local-realm. This
keeps the existing authz file working and they can grant access to
users from remote realms easily.

4. Administrators who are extremly trusting or have full control
over the administration of all realms they have cross-realm trust
with can set remove-local-realm and remove-remote-realm to use only
usernames and never realms for authenticating users.

Even longer story:

You're almost talking apples and oranges. Nothing in Subversion
uses plain Kerberos. Over HTTP, Subversion uses SPNEGO (aka
Negotiate) which happens to normally be backed with Kerberos, and
svn protocol uses SASL, which supports GSSAPI backed by Kerberos.

In the end though, it is all Kerberos doing the heavy lifting, even
though Subversion can't really tell that because the Kerberos is
wrapped up in SPNEGO on http:// or SASL on svn://. Also note that
ra_neon is the client half of the connection to a server which is
using mod_auth_kerb, and svnserve is the server half of the
connection from a subversion client. The more analogous part of
the connection is mod_auth_kerb, not ra_neon.

Here's the config info for modauthkerb:

http://modauthkerb.sourceforge.net/configure.html

This documentation is a little out of date; in 5.4 there is an
option, KrbLocalUserMapping, which when turned on (not recommended)
calls krb5_aname_to_localname. svnserve, right now, always
disables cross-realm and always does roughly what
krb5_aname_to_localname does, which is to strip the realm off the
authenticated name. So, mod_auth_kerb always enables cross-realm,
so it doesn't have a knob for it. It has a knob like
remove-local-realm, and then it doesn't seem to have a knob like
remove-remote-realm, probably because it seems like a bad idea,
although people do ask for it. If you'd like to simplify the patch
and get rid of remoe-remote-realm, I'm all for it. If you'd like
to simplify the patch more and remove the remove-local-realm option
and change the code to never remove the local realm, I'm okay with
it, but you'll annoy lots of people when them upgrade and have to
re-write their authz files. Removing the local-realm by default
and not providing a config entry to change it is probably forcing
administrators into a potentially unwise security situation.

Hope that helps. Let me know if you have more questions or other
ideas.

-- 
Alec.Kloss_at_oracle.com			Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956