Re: svnserve + SASL: Only works with plaintext 'userPassword', sowhat's the point?

On 26 Jan 2011 23:51:26 -0800, Nico Kadel-Garcia wrote:
>
> On Wed, Jan 26, 2011 at 9:26 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Wed, Jan 26, 2011 at 07:08:55PM -0700, Donner, Sean P wrote:
>>> > It's because of how CramMD5 works.
>>> >
>>> > "The server needs access to the users' plain text passwords."
>>> > http://en.wikipedia.org/wiki/CRAM-MD5
>>> >
>>> > Stefan
>>>
>>> Perhaps I'm wrong, but I was under the impression that the 1.6.x version of
>>> 'svnserve' natively supports CRAM-MD5; meaning you *don't* need to set
>>> 'use-sasl = true' to get this functionality.
>>
>> That's correct. But you can still configure SASL do to CRAM-MD5.
>> So there might be a bug in svn.
>> Maybe it still assumes that plaintext passwords will always be present.
>>
>>> So my original question stands as
>>> to what SASL is buying us when it still requires plain-text passwords to be
>>> stored on the server?
>>
>> Unfortunately the sasl stuff is not being maintained very actively.
>> The developers who wrote it aren't active anymore.
>> There are a couple of outstanding issues (some with half-done patches
>> floating around) that haven't been addressed due to lack of interest
>> and resources.
>>
>> So if you want to help out with investigating this problem more closely
>> and possibly also help with fixing this the Subversion project would
>> be grateful.
>
> Or switch to svn+ssh for SSH key based access, which has other
> advantages.

I use svn+ssh, multiplexed through a single account. I enjoy the
advantages this provides.

One thing I do, though, may not be the most secure. I'm wondering
about the risks of not starting svnserve directly in the svnuser's
~/.ssh/authorized_keys file, but instead using a wrapper script. What
I put in the authorized_keys file is something like

     command="/home/svnuser/bin/svnserve_wrapper \
     full.user.name",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty \
     ssh-rsa <long public key> useraddress_at_someplace.com

     (line breaks added for clarity)

In my svnserve_wrapper, I start up svnserve as follows:

,----[ svnserve_wrapper ]
| #!/bin/bash
| # This is a wrapper for the svnserve command.
| #
| # Adjust parameters here
| SVNHOST="hostname.someplace.com"
| SVNPATH=/path/to/Collabnet_Subversion/bin
| SVNROOT=/path/to/svnroot
| #
| # Here's why we're running svnserve via a wrapper:
| # It allows us to
| # * Make changes in a single location instead of having to
| # edit ~svnuser/.ssh/authorized_keys
| # * Enforce access through a single host
| # * Set up correct umask
| # * Change PATH to find correct version of svnserve
| # * Set up path to svn repository
| # * Log subversion access
| #
| # Enforce single host:
| [[ "$(/bin/hostname)" = "$SVNHOST" ]] || {
| echo "Unauthorized host: svn+ssh access permitted only through $SVNHOST"
| exit 1
| }
|
| umask 077
| export PATH=$SVNPATH:$PATH
|
| # Do logging
| # Format is YYYY-MM-DD-HH:MM:SS userid svn-args
| echo $(date -u '+%F-%X') "$@" "$SSH_CLIENT" >>/home/svnuser/svnlogs/`date "+%Y-%m"`
|
| # extract the user id
| userid=$1
| shift
|
| # execute svnserve in correct format
| exec svnserve -t --tunnel-user=$userid -r $SVNROOT ${1+"$@"}
`----

Are there security risks in starting up a shell script instead of a
compiled binary?

Ted

-- 
 Frango ut patefaciam -- I break so that I may reveal