Thank you very much.
On 07/28/2011 09:48 PM, Geoff Hoffman wrote:
On Thu, Jul 28, 2011 at 7:29 AM, Andy Canfield
<andy.canfi...@pimco.mobi <mailto:andy.canfi...@pimco.mobi>> wrote:
<snip>
Hold it right there. You're providing password based
repository access
via HTTP, not HTTPS? Please rethink this unless you *want* the
passwords for this repository to be quite insecure and sniffable,
especially if you're using normal user login passwords.
If HTTP sends passwords in as plain text then yes, HTTPS is
better. But I can't get HTTPS to work at all. I get the impression
from googling that HTTPS requires a certificate, and I don't have
a certificate. If I could generate my own certificate, we could
tell our developers "Accept this certificate the first time you
see it, and after that it will work every time."
</snip>
<snip>
So there are actually four protocols that a workstation can use to
access a Subversion repository: http, https, svn:, and svn+ssh.
Assuming that I pick one, how do I turn the others off? If James
Bond can access via https, how can we prevent him from using http
and blowing the security? iIf James Bond has an ssh login account
on the server, but should not be using Subversion at all, how do
we prevent him from using svn+ssh:? How do we prevent him from
logging in and using file:? How do we prevent him from logging in
and running svnadmin?
</snip>
Wow Andy, you have really put SVN security through the ringer and
bring up some really good points.
Actually the people in this group are a lot more concerned with security
than I am.
Here I learned the difference between authentication and authorization.
I can trust the standard system alternatives for authentication - ssh,
http, https, SSL, whatever. It all winds up being "This guy is Charlie".
Then the question is, what is Charlie allowed to do? Seems like every
protocol uses a different method to do authorization, and that's my
ignorance. I'm trying to work out an authorization mechanism that
applies regardless of the protocol.
In recent years Linux has gone the route that a valid logged-in user can
read nearly anything. Can't change it, but can read it. Chalie can read
/etc/apache2/mods-enabled/mod_dav_svn.conf. But he can't change it. I
can live with that. Because we could have valuable trade secrets in a
Subversion repository, I would prefer to limit read access, but if that
isn't available so be it. But I am a little horrified that Charlie can
create repositories without any authorization at all.
I keep comparing Subversion to MySQL. They both store data for you. A
repository is like a database. But the average user is not allowed to
create databases! Everything you do with MySQL - create, drop, update,
select, etc. - goes through the same piece of code; the server. So the
MySQL authorization scheme is exactly the same regardless of how you get
to the server; it's built into the server, not the protocol.
Apparently, regardless of the protocol, the Subversion library code
always checks $SVNParentPath/$Repository/conf/* and obeys svnserve.conf
and authz. So I need to learn to use that effectively.
We're hosting svn behind our firewall on http and so our users have to
have a VPN to connect. This of course requires a certain type of
security appliance (several hundred bucks at a minimum.)
In case it hasn't been obvious, I'm in southeast Asia, definitely third
world turf. And this is a startup, with stingy investors.
Some of our users have ssh login on the same box running svn but I
never thought to secure svnadmin or prevent svn+ssh so I never really
thought about it at the level you are doing. You can chroot users [2]
into their home dir if you go with svn+ssh... Matt's suggestion to
generate ssh keys for everyone is a good idea also (as well as making
it simpler to connect in a development workflow)
I would think https would be your best bet; you can make a self signed
certificate[1] but even an actual SSL isn't that hard to install and
only $20/yr from GoDaddy, for example.
Yes, HTTPS sounds like the best method.
I hate incorrect error messages. I once changed banks because their ATM
error messages were wrong. When I try to HTTPS into a serer that's not
configured for it FIrefox gives me an error message that says the server
response string was too long. That sounds like B.S. to me. Thanks to
you, I can make a certificate.
You can then detect http protocol with a rewrite rule and redirect to
https using mod_rewrite in either the vhost container or .htaccess file.
Where would the .htaccess file be for svn+ssh? There's no directory!
Have you thought of getting some paid help from, e.g., CollabNet [3]?
Maybe well worth it in your case. (Case STUDY more like it!)
[1]
https://help.ubuntu.com/8.04/serverguide/C/certificates-and-security.html
[2] https://help.ubuntu.com/community/BasicChroot
[3] http://www.open.collab.net/consulting/