Re: CVS & SSL

[Derek R. Price]

"Greg A. Woods" wrote:

> [ 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!

Uh, no.  I believe we were discussing the patch I just wrote?  I was referring 
to
prefering an SSL'd socket to an SSH tunnel, especially when, as the "tunnel" 
part of
"SSH tunnel" implies, I was going to be running pserver over either connection.
Please note the distinction between the words, "want" and "do" as regards my 
earlier
text.


> 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!

I, personally, don't want to stop anybody from setting up dumbsite.org, where 
any
bozo can click on a link on my website and get a pserver account with write 
access to
my repository.  Nor do I feel I should force such a person to give each and 
every one
of those users a pserver account.  Just because *I* am paranoid doesn't mean I 
feel
I should force others to attain my own personal level of paranoia and not every
project *deserves* the same level of paranoia, even in my own paranoid psyche.

And SSH does more than I need it to for many cases.  An SSL socket provider 
seems a
reasonable lightweight alternative.


> > 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".

Um, yeah.  I believe I mentioned this already.  Perhaps I wasn't clear or you 
haven't
seen my reiteration yet.  It's possible that this deserves attention in the 
manual.


> 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.....

If you have this much time on your hands for this sort of thing, please work 
_with_
us.  Few enough people contribute as it is.  Fewer still that know the code 
base very
well.  Submit patches.  Discuss the issues.  Please don't try to limit CVS to a
single security model, however.  SSH & RSH are all well and good, but they are 
not
available for every platform and some sysadmins are understandably reluctant to 
grant
shell access to every CVS user.


> > 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).

By limiting CVS to :ext: you are limiting the choice of security models to those
which provide _shell_accounts_on_the_server_!  The socket provider model allows 
for
any sort of security model that can provide a tcp connection and uses its own 
methods
to determine user names for the logs.  As for the security of the pserver auth 
for
log names, well, yeah, it's fairly insecure.  An appropriate and backwards 
compatible
upgrade for this might be something like PAM.  Of course that probably doesn't 
work
for all platforms.  I believe Alexey Mahotkin did this for nserver already, so 
we
might see it in CVS if his code ever makes it into a mergable state.  His recent
questions lead me to believe he is at least updating his changes to work with
1.11...  :)


> 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)

No, really, you _don't_ have to run pserver as root.  Curently.  As implemented.
Didn't you just repeat this above?


> > 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.

Aside from the issue that RSH & SSH haven't been ported to as many platforms as 
CVS,
some sysadmins are understandably reluctant to grant every CVS user a shell 
account.
I think a plugin socket makes sense as an intermediate level of security.  
Again,
some sysadmins would probably consider it *more generally* secure, even if it 
weakens
CVS's internal security slightly, because 
_they_don't_have_to_grant_shell_accounts_.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden         CollabNet ( http://collab.net )
--
"If I was modest, I'd be perfect."

        -Ted Turner