-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guus Leeuw jr. <[EMAIL PROTECTED]> writes:
> > > Hence I am looking at the pserver protocol, so I figured, it is a FAQ. > > > Now depending how you interpret FAQ (asked or answered), I was right ;) > > > > > > It's apparently asked often, but > > > https://ccvs.cvshome.org/fom//cache/446.html gives no answer :( > > > > Search the info-cvs archives and you might have more luck. The short > > answer is don't use it. Move along, this is not the protocol you are > > looking for... > > The "hence" above was indicating that I am writing a passwd command for the > pserver stuff, as Jim suggested would be a nice feature... > On dev, so far, no hard statement against doing this... > If you think, I shouldn't be doing this, please state so, and I'll back out > doing more important stuff... Larry and Derek would both need to agree with me that pserver needs to be killed before we could rip things out of the feature version. I doubt that will happen given how many folks still use pserver out there. There is also a CVSNT fork of CVS that has even more ways to 'authenticate' the client for server operations... they also have the command you are talking about writing. Have you considered moving to the CVSNT fork of CVS? (Yes, it runs on boxes other than Windows.) > > > Can anybody tell me where the doc is? Can't seem to find it in the > > > cvs1-12-11 branch... > > > > For HTML Cederqvist manual for cvs 1.12.11, look here: > > https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs.html > > > > For the client/server protocol, look here: > > https://ccvs.cvshome.org/source/browse/ccvs/doc/cvsclient.texi > > > > You should be able to find a doc/cvsclient.info file and a > > doc/cvsclient.ps -- these forms of the document describe both the > > pserver framework and protocol (as well as the kserver and server > > protocols). If you plan to read the document closely and you actually > > care about security, issue ear-plugs to your neighbors so that your > > screams will not distrub them too much. > > OK, thanks ;) You are welcome. > > 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. Root has too much power to run an untrusted application that has been in the past and likely will be again in the future subverted into letting an external agent execute undesired operations as root on the server machine. If you look at the main page (https://www.cvshome.org/) you will see that even cvshome.org was subject to an attack on a cvs security violation. 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. The only time it might make sense to have a "pserver" server running would be in a read-only mirror replica of an existing repository on a machine that may be re-installed on a moments notice WHEN (not if) it is found to have been compromised. If said read-only mirror was providing 'anonymous' checkouts, then that might be a useful case for "pserver" mode to exist (I would still rather see anonymous ssh transport for such purposes.) > > If you are using pserver, I hope it is on an isolated LAN with lots of > > firewalls and does not control any sources you really need to be kept > > secure. I also hope that you are making plans to transition away from > > pserver usage as fast as possible. > > I use it since a couple of years on a LAN that has merely an ADSL router > listening, and a linux based firewall blocking... in between the LAN and the > server is still an SMC Barricade allowing nothing from the outside to create > a network session... Guess this is triple secure... I get a lot of probes, > but they don't make it through the server... So that should be cool... That might make it a bit more difficult and the 'bad guys' may go looking for easier pray. > > Summary: Friends don't let friends deploy cvs pserver configurations... > > 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. > 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? > So we might consider implementing it, no? I can't stop you. > 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. How many botnets are running on your internal network today? How certain are you that the next virus that attacks a machine inside of your current firewall won't be used to attack your CVS server to send copies of proprietary source files or documents to a third party? (Leaving aside that if they own the client they can already send copies of all of the files that are currently checked out, of course). Such programs could possibly just read and forward a .cvspass file contents laying around from some user and so get a bit further into the protocol than the first few auth exchanges. > 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. 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. 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 cvshome.org, 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:[EMAIL PROTECTED]:/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. Good luck, -- Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCDyO63x41pRYZE/gRAqlYAKDl8LiKd2IF92hwQf8qkr7UWe+NFACePnxY xoF4dLbNhYz4tku4lXp1cWQ= =0fTH -----END PGP SIGNATURE----- _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
