info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David A. Desrosiers
Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
Date: Thu, 21 Feb 2002 18:38:15 -0800 (PST)

> There's only _EXACTLY_ one case where cvspserver is in any way more
> secure than giving out real accounts, and that's when pserver is used to
> give read-only anonymous access to a _copy_ of a repository.

        And if the copy needs to get sync'd back to the "real" repository (a
definate requirement), there goes your security. Next idea?

> In other words if you've given an account to an user to access a CVS
> repostitory hosted on your network then you _MUST_ do whatever is
> necessary to isolate that user's access from the data and services on
> your network and in your systems that you do not trust them to access.
> I.e. you give them limited trust.

        i.e. you give them no access. Hence, pserver. I don't want to give
out shells to hundreds and thousands of developers using ssh. Using pserver,
this works today, and is much more secure. I don't need accountability, I
need security. pserver vs. ssh are not even _CLOSE_ to a comparible item.

> This also implies that you _MUST_ equally trust each user of the same
> repository at the same level.  If an of those users is also to be
> trusted with more access to your other systems then you MUST give them a
> different unique user-ID and separately authenticate them for the higher
> level of access.

        Thanks for the lesson, I'm away of how to do system-level and
account-level administration. I'm also aware of how to secure the system,
and the services hosted on it.

> In other words you must comparmentalize access to your shared CVS
> repository so that remote users can gain secure access to it while not
> gaining access to anything you don't want them to access.

        Gee, sounds like pserver again. Once you hand out an ssh account,
you give them a huge truck to drive through your wall of security,
authenticated and validated.. with absolutely _NO_ verifyability that the
user on the other end is who you think it is.

        It's an interesting idea, however.. not usable as users scale into
the thousands.


/d





reply via email to

[Prev in Thread] Current Thread [Next in Thread]