<<< Date Index >>>     <<< Thread Index >>>

Re: CVS woes: .cvspass



[ On Thursday, July 29, 2004 at 16:30:07 (+0300), Delian Krustev wrote: ]
> Subject: Re: CVS woes: .cvspass
>
> On Tuesday 27 July 2004 23:20, Greg A. Woods wrote:
> > Anyone using the CVS pserver mechanism for anything other than totally
> > anonymous access gets only what they deserve.
> 
> brr, do not forget that the security might be guaranteed on different
> layers. E.g. ipsec secures the insecure protocols(the ones that transfer
> data in plain text or with weak encryption), such as telnet or cvs
> with pserver.

Nope, sorry, but that's just not possible, at least not with CVS pserver.

The unix security model, within which CVS is designed and implemented to
work, _requires_ unique user-IDs for each and every unique human user.

This is in fact a basic, fundamental, requirement of all systems of this
type.

CVS is not, and cannot be, a security tool so running it as root and
pretending to have it do all your authentication and authorisation flies
directly in the face of the underlying system security model and leaves
you with no real and verifiable accountability whatsoever, and it also
leaves you open to the possibility of yet another vulnerability vector
in the form of the unaudited CVS code base.  Remember that the vast
majority of all security incidents originate internally to the
organisations they affect.

Admittedly we're talking about what are effectively C1-class systems,
or C2 at best, but none the less the same basic fundamental principles
apply.  On the other hand if CVS is used only as it has been designed
and implemented to be used, it could in fact be used on even a B1-class
system without any risk of additional vulnerability or compromise.

If you think your network is secure enough courtesy other mechanisms
then you can use RSH instead of SSH, but DO NOT try to use cvspserver
for anything but totally anonymous access.

The risks of cvspserver for totally anonymous access can be mitigated in
several other ways, but there's no way possible to mitigate those risks
when you try to pretend to use it for developer access.

-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@xxxxxxxxxxx>
Planix, Inc. <woods@xxxxxxxxxx>          Secrets of the Weird <woods@xxxxxxxxx>