Brian Mathis <bmathis@directedge.com> writes:
> I was thinking the same. IMO, directly accessing the files via file:
> method and svn+ssh: is a really bad idea unless there's only 1 person
> using it (ie, personal projects). The Unix permission scheme just
> isn't cut out for robust multi-user sharing like what needs to be done
> with svn.
Unfortunately, svnserve is not an appropriate program for me to be
advising people to put on an unprotected server. The svn+ssh method
seems to be perfectly fine, provided that some small changes (and we
are talking only 20 or 30 lines) are made so the tools can be run
setuid "svn" or some such.
> Go with apache/mod_svn or svnserve for large projects.
Apache is far too large to be audited and was never written with a
security architecture in mind. It is a fine web server -- but it is
not a fine secure access service.
If what you are doing is defending the machine running your candy
store's web site, there isn't any problem here. However, if, say, you
are defending the source code for something very valuable and there
are loads of highly motivated people who would love to make unseen
changes to it etc, you cannot be nearly so trusting.
I do security work for a living. Proper security hygiene says:
1) Run very few outward facing services on a machine that will be
attacked -- as few as you can. Each server process you run is a
potential weak spot, and the programmers are in each case fallible
and WILL have made mistakes. The more services you run, the higher
the likelyhood of one of them having a mistake that makes it
vulnerable to attack.
2) Carefully defend each of the services you have to run to the best
of your ability.
On my personal boxes, for example, I run named and ntpd, but in each
case the process is run unprivileged, chrooted and tied up with Niels
Provos' wonderful systrace system that restricts the system calls each
can run. I also run sshd, but I run it priv separated and with
systrace to the extent that I can.
Is this perfect security? No, but it is a damn sight better than what
most people out there do, and it would be a much higher barrier to
attack. I'm sure things will be broken into some time, but it won't
happen nearly as often as it will for other people who aren't
careful.
Is it paranoid or dumb to run things this way? No. We live in a world
where the tools for doing break-ins are now automated, and where a new
Linux box put on the net can expect its first break-in attempt within
five minutes. No, that's not a joke. That's just the truth -- run an
IDS system some time and see. Assuming you should be careful in how
you set things up is the only sane way to run things. Its like
wearing seat belts -- you're still at risk, but the odds are much
better for you.
Is it inconvenient running things this way? Not in the least. It takes
a little more time setting up your named to run chrooted and unprived,
but once it is set up you never notice the difference again -- and you
don't have trouble sleeping at night.
So lets get back to Subversion. You ask me, merely to run a version
control system for a few users, to add on things like apache and/or
svnserver. I have no need to do that -- there is already ssh for
remote access, and svn works with that quite well from what I can tell
modulo a couple of nits. Even if I believed the developers of apache
and svnserver were saints, I am increasing my vulnerability -- and for
no obvious gain. As it happens, I don't believe in the perfection of
the programming work done by the Apache people or anyone else.
So, call me a kook if you like, but there are many projects I
participate in, like NetBSD, that agree with me about the importance
of security and making sure that you minimize the threats to the
extent that you can if you're doing important work.
As for what changes are needed here, as I said, simply allowing the
tools for svn+ssh access to run suid "svn" or "src" or some such would
likely fix the only problem I have with it right now. Yes, holes in
those tools might give the users unlimited access to the "svn"
account's privs and thus the repository, but as it happens the
universe of users is fairly small and well trusted, and in any case
can do pretty heavy damage just by committing buggy code.
So given the minimal changes I need to get *exactly* what I want, and
the non-existent gain in using the other access methods, I don't see
why I would want to use apache or svnserver.
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 13 18:42:15 2004