> Please correct me where I go wrong here: I guess that use of a Simple
> Authentication and Security Layer (SASL) would require svnserve to make contact
> with some other process on some machine.
That's where you go wrong :-)
Most SASL libraries require a running authdaemon. However, it is usually
only required when the SASL library on the server side needs to
authenticate against system credentials to which it doesn't have access
(think /etc/shadow). The authdaemon running as root (or some other user)
just consults the priviledged backend data store and yays or nays
requests from the server process.
If you don't want an authdaemon, don't use one. But don't try to
authenticate users against data stores that require some kind of
priviledged access on the system :-)
Now, I'm no expert in SASL, and I understand that some implementations
actually route *any* authentication request whatsoever to the
authdaemon. The authdaemon then decides what data store to look it up in
based on its configuration. But this doesn't mean it needs to run as
anyone specific. What user it runs at just limits what data stores it
can look up to answer the request.
> So the addition of SASL would
> change the relatively simple svnserve setup (one simple enough for users to
> administer) into something much more like https/Apache/DAV access in terms of
> the config complexity and admin support required.
Sadly, authentication is not a simple problem by a long way, so adding
SASL support will make the configuration more complex, that is for sure.
However, I disagree that it will systematically require "admin care and
feeding". If you want svnserve to authenticate against /etc/shadow, the
admin will have to start the authdaemon as root, that makes sense. If
you want to authenticate against a plain ol' htpasswd-like file, the
authdaemon can run as the svnserve user, or even not run at all,
depending on the SASL implementation.
The point is, real SASL will give the users and admins a choice in the
matter - a setup as simple or complex as you like!
> Maybe you're saying that svnserve would negotiate an SSL session each time a SVN
> client connects to it. Given the availability of OpenSSL, is this difficult?
No, but that won't eliminate the need for new SASL authentication
mechanisms. And there, we can either implement
yet-another-SASL-implementation, or use a proven, mature library to do
so. What I meant is that some SASL mechanisms are only secure if used
over a secured communication medium, such as what SSL provides.
> Would this allow eliminating cleartext keys because replay attacks are then
> very difficult? The new complexity in that situation is an SSL certificate (I
> think). Would one be required per repository served by svnserve, or only per
> machine where svnserve is running? Ideally the latter, so the hassle can be
> limited to install/setup, not each time a user wants to create a new
> repository.
The choice may not be ours to make: the certificates are exchanged when
the connection is initiated, before any other communication occurs. As
such, svnserve would not know which repository it is serving until after
the secure tunnel has been built (unless we mess with StartTLS to build
a secure tunnel halfway into the communication). This is why you can
only have one HTTPS host per IP without browsers complaining about
invalid certificates: certificates containing the host name are
exchanged before the HTTP protocol comes into play and tells the server
what host it wants serving.
> The proposed password-management policy of generating/caching obscure passwords
> for all SVN users, as Greg Hudson stated, only lessens the chance of a user
> storing a password that s/he uses widely on various systems. I agree that in
> our case, everyone works for the same company, so they should ask each other
> for access instead of taking it. But the cleartext issue seems like an
> avoidable hole.
It is avoidable, no doubt about it. The question hinges on *how* we want
to avoid it: hack support for a nonstandard authentication method into
Subversion and be stuck with it for ever and ever because of
compatibility issues, or abide by standards that are meant to make
applications behave in similar ways in reply to similar problems and
that have mature code ripe for the picking?
I am in favour of the latter. I'd be in favour of the former as well as
a temporary fix, but compatibility policies say that if we start
supporting "cram-md5-digest-svn" today, we'll have to support it at
least until 2.0, which is a very long time for a temporary fix. And
adding a nonstandard mechanism means integrating a real SASL library
later on will be next to impossible to do cleanly and/or without
violating some standards and/or without writing horrible code that
defeats the principle of using a SASL library.
> One small item -- David Anderson's original proposal states that cleartext
> passwords are not a security issue. Well, I guess I beg to differ; I feel it
> is a real security issue.
What I meant by that is that they are not a security issue if the
password data store is protected and an adequate password attribution
policy is used. That sentence was meant to dispell possible FUD that "if
it's stored in plaintext someone could intercept it during the
authentication exchange", which is exactly what cram-md5 prevents. The
issues are more social (people reading other people's passwords make
people uncomfortable), with a borderline security problem in some
borderline cases (including your setup).
In conclusion, please be assured that I am receptive to what you are
saying - That's why I want to take on SASL integration, to provide you
with a solution, and do it the Right way. My original quick-fix proposal
was just that - a proposal. Greg and others gave me the answers I was
seeking as to "why don't already do this?", and I find the arguments
compelling. I will be tackling SASL integration once my current work is
finished, so don't worry: the cavalry is on the way ;-).
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 29 02:27:29 2005