Re: ANN: cvssh - secure ext-to-pserver bridge

[Kaz Kylheku]

In article <address@hidden>,
David A. Desrosiers wrote:
>> Duh.  If you're doing authentication and authorisation on a unix-based
>> file server then you MUST, _M_U_S_T_ use a unique system account for
>> ever real-world user or else you might as well not use any
>> authentication whatsoever.  Pserver has NO accountability from the
>> system's point of view.  None whatsoever.  Don't use pserver.  Ever.
>
>       Except in the cases where using pserver is actually _MORE_ secure
>than giving users a valid unix account on your server. I could very well
>trust my developers, and give them shell accounts, but I can _NOT_ trust
>their machines, their network, their personal accountability when they 
>are 9,000 miles from my location.

What, distance causes mistrust? ;) How exactly does trust vary with
distance? Inverse square? Or something more exotic like inverse cube? ;)

But then some of the nastiest things that people do to each other are done,
out of logical necessity, from close proximity.

>I have developers all over the world
>using my services, all with pserver, because the "risk" (which there is
>none) is completely negligable. The risk of giving out hundreds and 
>thousands of unix accounts, however.. is _HUGE_. No thanks, pserver is 
>much, much, much more secure for my needs, and the needs of my developers
>in this instance. 
>
>       Also, giving a user a shell, even chrooted, or blocked from the 
>ability to log in, consumes much more process and resources on the box, 

Who says you have to give users a shell? Their registered shell program
could in fact be a script that only allows CVS access.

I have a shell script which allows users to use CVS, but only to a
specified repository path, and also allows secure shell copying (scp)
to and from their home directory. This script, called cvs_or_scp_only
is installed as the login shell.

>and definately scales linearly, and is open to much more exploitable 
>holes than what pserver provides. The risk of sniffing the password is
>nil using pserver, since obtaining it gives the "cracker" exactly 
>nothing. Are they going to commit code on our behalf? Unlikely. 

You think that someone specifically stealing a CVS pserver password is
unlikely to screw around with your CVS repository? Hahahaha.

>Delete a tag? We can roll back out. It's all negligable. 

What if the tags are merely altered? What if you don't notice a malicious
alteration for months? Will you restore your files back six months?

>       
>       pserver with strong host-based controls on the open port, using

``strong'' and ``host-based'' is an oxymoron. IP addresses can be spoofed.
The more hops between you and the host.

If any of your users are from the same network, they can steal each
other's passwords easily, and spoof each other's addresses, if not indeed
use each other's machines.
 
-- 
Meta-CVS: version control with directory structure versioning over top of CVS.
http://users.footprints.net/~kaz/mcvs.html