Re: Subversion security design

On Mon, Jun 26, 2000 at 06:55:42AM -0400, Jonathan S. Shapiro wrote:
> > ...we're
> > deliberately *not* discussing any particular authentication or
> > authorization mechanism.
>
> > Authentication and
> > encryption? Those issues are the network layer's business; after
> > authenticating (possibly over a secure channel), it simply needs to
> > pass the server library a filled-in `svn_user_t' structure.
> > Authorization? That's a server-side plugin. Folks can implement any
> > ACL system they wish, provided they conform to our interface.
>
> I've been thinking about this assertion, and I've concluded that I disagree.
>
> For link-layer protection, link-layer encryption is fine. SSL is a perfectly
> reasonable way to stop people from snooping your connection so long as the
> cert is properly installed.
>
> For the authentication and authorization, though, I don't think it's so
> simple. True enough, many people will be content with a PAM-style plugin
> (speaking of which, are you considering using PAM?).
>
> The problem comes in distribution and replication. If my site mirrors your
> site, then it probably ought to mirror your access policies for your
> content. This creates a challenge, which is that there is no longer a common
> administrative domain for assigning user identities. For this reason, the
> notional DCMS mechanism is public key cryptography. I'm not sure if that
> will work either, but I'm absolutely certain that nothing based on a
> uid-like structure will distribute.

How does your mechanism work in an NTLM environment? In a Kerberos
environment? How about my good old /etc/passwd -based Linux box? Is your
authentication system sound? Has anybody else implemented it and reviewed it
from a security/crypo standpoint.

Subversion can operate in all of these authentication environments without a
problem. In each case, there is a well-defined mechanism for clients to
authenticate with the server via HTTP + the specific auth mechanisms. The
core of Subversion does not have to worry about this stuff. No coding, bugs
are somebody else's problem, better interop, and we get it all *today*.

Distribution and replication... yes, this would be a bit harder. But not
necessarily. Imagine a Subversion software package/release which uses MySQL
for its authentication information. The package could include the tools for
dist/replication which also include the MySQL tables.

But then somebody else packages one up that uses NT's distributed auth
systems.

(and yes: I believe there is a mod_auth_pam for Apache, which uses PAM for
 the authentication)

If site A mirrors site B, then it is possibly a moot question on whether
site A would also need the auth information. Aren't the auth'd users only
doing their work at site B?

Subversion maps all users, by whatever auth system or mechanism, into a
simple string. e.g. "kfogel" or "gstein". I don't see how that is a problem.
Possibly, if you attempt to create a union of different repositories, then
you could have a name clash. I'd posit that is an unimportant problem at
this standpoint, and I would maintain easily remedied (by a simple transform
across the userid strings; gstein becomes gstein.lyra.org).

I'm not sure what else you might be looking for. I may not have explained
well enough. But I can say, that implementing a whole new authentication
system is a non-starter. I may have missed your point, so I'd welcome
further thoughts from you.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/