Re: CVS & SSL

[Greg A. Woods]

[ On Thursday, May 24, 2001 at 08:58:22 (-0400), Derek R. Price wrote: ]
> Subject: Re: CVS & SSL
>
> I don't _want_ to take the trouble to set up a separate SSH tunnel each time.
> And I don't like allocating and tracking ports on my local machine for each 
> CVS
> server I connect to.

Wait a moment here.  You mean you're using CVS Pserver over the open
Internet to sites that give you write access?  That's pretty bad.  You
should know better!

If you were just using CVS_RSH=ssh as it was intended to be used then
you'd have no problems or worries at all.  You should FORCE any
repository owner who grants you access to allow you to use SSH, not just
for their own good, but for your protection too!

Yes, pserver for anonymous access is different and so terribly
entrenched that it probably won't go away any time soon, but that
doesn't sound like what you're using it for.....

> The setuid's been there forever.  pserver is intended to run as root and set 
> its
> ID to whatever user the passwd file maps the login to.  How did you think that
> was working?

Then it is still broken as designed.  It should NEVER EVER use setuid!
It is not secure and cannot be used safely that way (at least not on
most modern platforms, my hacked NetBSD kernel aside)!

Many times in the past there have been explict instructions posted to
this list (and not just by me) showing how CVS pserver could be designed
and implemented safely without setuid.  It is so totally bogus that it
has not yet been fixed that I'm just appalled.  In fact I'm pretty sure
that I even did a test implementation of pserver running the publicly
released CVS without root privileges and it "just worked".

Maybe I need to ask for people to help me to produce a new release of
CVS based on my current private work so that a safe alternative
implementation is publicly available.....

> Few _sysadmins_ seem to agree about which security models are best.  Thus, it 
> is
> best that CVS remain flexible enough to provide varying levels of security
> dependant on the desires of the administrator.  For now this means keeping
> pserver around, I think.

It is because of this issue that CVS MUST NOT implement *ANY* security
model!  CVS already provides all the necessary hooks so that *any*
external security model may be implemented.  There's really no need for
pserver (and there never ever was).

If CVS simply offered only the :ext: method and forced admins to use
either rsh, ssh, or some similarly capable remote execution facility
then it would be much harder for anyone to blame CVS for inherent
security flaws, and it would be much harder in fact for admins to choose
an insecure access method (most would no doubt just choose SSH because
it's available and works right "out of the box").

> Keep in mind too that some people use pserver for the user maps & logging,
> probably not even really caring whether it is particularly secure itself.

That would be OK, but apparently NOT with the current implementation --
only without setuid!  (and only for read-only access to a safe mirror if
you care at all about the content of your real repository)

> Finally, note that all I did was enable the insertion of a socket provider in
> place of CVS's internal tcp connection.  This enables the further removal of
> security from the CVS application itself.  Your socket provider can be
> authenticating using any method you wish and pserver continues to allow the
> mapping to separate userids in the logs without necessitating separate user
> accounts.

There's no need to provide anything other than :ext: support using CVS_RSH.

Offering more hooks for people to make more stupid choices is not productive.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>