Well, if I can't use https://, I would use svn:// tunneled through a SSH
connection... Am I missing something on this approach?
Luis
Perry E. Metzger wrote:
>Ben Collins-Sussman <sussman@collab.net> writes:
>
>
>>Perry E. Metzger wrote:
>>
>>
>>
>>>Er, unfortunately, for good or ill, many people need to use
>>>ssh. Sometimes this is simple good security sense -- you want to avoid
>>>opening additional attack vectors for a machine.
>>>Given that, what might I be able to do to tighten down the on-machine
>>>security without adding another bunch of code to audit talking
>>>off-machine?
>>>
>>>
>>SSH isn't the only "safe" way to access a computer.
>>
>>
>
>That's not the point. Good security policy says that every program is
>buggy, and you thus want to rely on as few of them as possible. That's
>sometimes called "aperture narrowing" by those of us who do security
>work professionally (like me).
>
>Most break ins are not caused by problems in protocols or failures to
>encrypt -- they're caused by bugs in programs (like buffer overflows)
>and problems with configurations.
>
>Fewer services listening means fewer ways to break in and fewer
>systems to audit.
>
>
>
>>One solution is to use apache as your svn server, with SSL. Clients
>>access via https://.
>>
>>
>
>Some people prefer not to do this. Apache, for instance, is a very
>large program compared to ssh, and is much harder to audit. Also, if
>you already have ssh running on the box, you might not want to have to
>add a second service if you can avoid it. See above.
>
>Really, what I'm looking for is to make the access method to the
>repository SUID to an "svn" account and get to it over ssh. That means
>that the developers may have a potential way to break in to the svn
>account if there are bugs in the access program, but I'm not that
>concerned about that -- the main purpose is to keep them from
>accidently damaging the repository rather than to provide "real"
>security here. We mostly trust the developers and just want to stop
>accidents.
>
>However, we don't trust the wider world and would like to keep the
>machine otherwise as tied down as possible -- which means ssh access
>only.
>
>
>
>>I'm just brainstorming here.
>>
>>
>
>As I said, the easiest thing of all is probably the 30 lines of code
>needed to make the local access method successfully use suid. It
>should probably just open the files it needs, record the real user ID,
>and drop privs. Alternatively, given that we're talking suid "svn" and
>not suid root, it may be sufficient just to record the real user ID so
>that the right user is recorded in the logs etc...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 13 17:30:25 2004