On Sun, Aug 06, 2000 at 07:53:43PM -0400, Greg A. Woods wrote:
> Yes, it is a cvspserver problem, and *only* a cvspserver problem. The
> number and consequences of bugs in any version of CVS not using
> cvspserver are totally irrelevant from a security point of view because
> the only way they can ever be exploited is by someone already
> authenticated and authorised to execute code on the server in question.
Get rid of the "professional software shop" training wheels please.
I provide CVS access to people I don't know very well. I provide anonymous
access to my CVS tree as well. In an environment like that it is *not*
just a pserver problem. I need to make sure that, in the event one of
these people turns out to be a bad apple, they don't get out of the box
I've put them in.
First, I use chroot to restrict the number of files they can read (and
write) so they can't use CVS to romp through my whole OS.
Second, I use Unix permissions and groups to restrict which files they
are capable of altering inside that box.
And please don't tell me that CVS would allow me to figure out who did
what. Given a shell on the main root there are LOTS of dirty tricks you
can play that don't leave too many tracks. It's very difficult to secure
an entire machine against users with shells. It's not so difficult to
secure them when they're locked in a little chroot with hardly anything
inside of it.
Your assumption that everyone who is authorized to access CVS is
trusted in general is FLAWED.
pserver plus the --chroot patch offer a workable solution to the problem.
> This is because CVS, by design and implementation, assumes the user
> already has shell access.
And when you use the --chroot flag that assumption can be restarted as
assume they have a shell inside the chroot only.
Justin
