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.canfield_at_pimco.mobi <mailto:andy.canfield_at_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/
Received on 2011-07-29 03:27:36 CEST