[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ssh based access?

From: Sean Russell <ser_at_germane-software.com>
Date: 2002-04-16 16:09:47 CEST

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue April 16 2002 00:09, Greg Stein wrote:
> There is nothing to support that Apache has problematic buffer overflows.
> Most of the problems over the past year or two have been related to poor
> processing rather than overflows. We've had a couple overflows on Windows,
> but that's about it.
>
> Heck, there isn't anything that says that Subversion doesn't have buffer
> overflows. New code. New problems.

His point is that it is easier to sandbox repositories with the hypothetical
ra_ssh.

Currently subversion and apache are running as a privileged user of some sort
- -- httpd, nobody, what have you. A buffer overflow exploit anywhere in the
architecture will give the attacker access to at least a shared repository.

With ra_ssh (or whatever), you open up a new possibility for sandboxing: each
user can create their own repository in their own home. Subversion processes
are run as that user, and any failure of security in the system will affect
only that user's repository.

Additionally, there is only one point of attack: the sshd daemon. To break
ra_ssh, you'd need to break sshd, because you tunnel through SSH to start the
subversion server process. SSH is a sort of firewall. With ra_dav, there
are multiple points of attack, as you've pointed out: httpd itself, mod_dav,
whatever.

> And you know... for that matter, has anybody actually audited CVS? Hoo... I
> have seen its network code. Ohmigod. I double-dare you to audit that.

Right... but the exploits of CVS are really limited, when used via SSH. In
that case, the CVS server runs as the UID of the user, and your only access
to it is through SSH. IE, if you've got that set-up, it doesn't matter if
CVS is weak, because if you have SSH access to that account you can mess with
the repository directly.

I *think* the confusion is about the nature of how ra_ssh and ra_dav would
work, on the server side. ra_ssh is all about user processes, running in
user space (except for the SSH daemon itself). ra_dav is about global
processes, running in a public space. The only way you could simulate the
sandboxing you get with ra_ssh would be to run an Apache process as each
user, local to their $HOME.

- --
 |.. "To the youth of America, I say, beware of being trivialized by the
<|> commercial culture that tempts you daily. I hear you saying often
/|\ that you're not turned on by politics. The lessons of history are
/| clear and portentous. If you do not turn onto politics, politics
 | will turn on you." - Ralph Nader
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vDCrP0KxygnleI8RAtHQAJ0U84gRbp5HtXfsoILdo5ENJII/8gCfelvm
cT7jBHXhsYdZLu8XCe8aqmc=
=KQ/9
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 16 16:10:58 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.