[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
>
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 (https://www.cvshome.org/) you will see
> that even cvshome.org 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 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: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.
Guus
--
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