[Top][All Lists]

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

RE: FAQ-O-Matic pserver protocol

From: Guus Leeuw jr.
Subject: RE: FAQ-O-Matic pserver protocol
Date: Sun, 13 Feb 2005 13:13:12 +0100

> -----Original Message-----
> From: address@hidden [mailto:address@hidden On Behalf Of Mark D.
> Baushke
> Sent: dimanche 13 février 2005 10:54
> To: Guus Leeuw jr.
> Cc: address@hidden
> Subject: Re: FAQ-O-Matic pserver protocol
> Hash: SHA1
> Guus Leeuw jr. <address@hidden> writes:
> Have you considered moving to the CVSNT fork of CVS? (Yes, it runs on
> boxes other than Windows.)

No, and I won't. I am a long time believer of CVS pure ;)

> > > In general, my personal opinion is that the pserver and kserver
> > > protocols should be removed from the cvs sources completely. It is
> never
> > > secure to run the cvs executable as root which is required to use the
> > > pserver protocol. The cvs sources were never designed with security in
> > > mind and running them as root is idiocy. (Just say no.)
> >
> > You're kidding right? Root is a good user(TM), no?
> Actually, no, I am not kidding.

Well, I was ;)

> If you look at the main page ( you will see
> that even was subject to an attack on a cvs security
> violation.

Yeah, I've seen that coming along.

> If cvs runs as root and allows connections on port 2401, then it had
> better be very well audited and have a very tighly written security
> model for dealing with all of its inputs and avoid all possibility of a
> privilege escallation that results in abuses to that connection.
> There is too much #ifdef'd code and hard to semantically verify code in
> the current pserver code path for any sane security expert to give
> anything better than an 'unsecure' rating to it.
> One way to deal with this problem would be to do something like OpenSSH
> does with priviledge separation, so that only a tiny fraction of well
> tested and closely examined code will ever run as root and that it
> carefully performs its authentication checks and validations. Further,
> it would not provide for a password that is only obscured on the wire,
> but is otherwise transmitted in the clear for use in any kind of replay
> attack you wish to imagine.

Hmm... Good idea... Takes a long time to implement, though... See below.

> > Sure enough... What about the people that do use pserver, and want their
> > users to change their passwords from CVSROOT/passwd?
> If they are going to move to cvs 1.12.x, then the could go ever further
> down the road to perditions flame and use PAM authentication and change
> their password via a NIS protocol if they want.

I'd assume most people out there use the CVS 1.11 branch of things, so I'd
stick passwd in the feature release for the hard-edge to test, and then
maybe a back-port?

> > No change today... Not securely, that is.
> Hmmm... that really is very funny. Sending the password in a completely
> reversible encoding otherwise in the clear to do normal operations is
> secure?

True, but such is the nature of pserver by default.

> > So we might consider implementing it, no?
> I can't stop you.

Well, if I'd do it, I'd do it because of:
1) It seems useful (Jim suggested such)
2) Larry, Derek, and you Mark would want it in the general CVS...

> > Simply sending a scrambled password over the *LAN* can't hurt too
> > much... For WAN, pserver is quite different ;)
> Well, the distance from a LAN to a WAN is a lot smaller than you might
> believe.

Sure, but LAN is controllable... WAN is not so much controllable...

> > Anyways... Development stopped until verdict is received ;)
> CVS is open source. There is nothing to say that you might not provide
> whatever patches you want to them and make them available to whoever
> wants them.

Yeah, again, I'm not going to devote my time to CVS development, when I'm
already certain the code's not gonna make it... That seems fair to me ;)

> That said, if you really are planning to cleanup pserver to make it
> 'secure' for changing a password, maybe you can find the time to do a
> more secure replacement code base for the pserver implementation
> instead? If you can get security folks to go thru all possible code
> paths and shake out the next big bug (and fix it), then I am sure
> a lot of folks would appreciate your work.

Maybe... We'll see. Let me first tackle the password stuff, and later, I
might have time to go about pserver in general...

> A strong believer in 'cvs password' should go and look at what CVSNT
> does. They already implement a 'cvs password' command. The protocol
> element they added is "passwd" so if you use that token in any code you
> submit to the CVS version from, then you MUST follow their
> protocol exchange rather than implement your own for CVS). We have tried
> very hard to ensure that nothing they add or we add will break the basic
> compatibility of a mixed client/server with CVSNT and CVS acting as
> either role.
> You will want a copy of the cvsnt sources. It may be fetched here:
>   cvs -d :pserver:address@hidden:/usr/local/cvs co cvsnt
> you would need to look at the cvsnt/src/passwd.c sources for their
> implementation. The cvsnt/doc/cvsclient.texi file has their
> documentation for the 'passwd' command protocol.

Yeah, that sounds like a fair start.


No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005

reply via email to

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