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...
--
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 15:44:55 2004