[Top][All Lists]

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

Re: FAQ-O-Matic pserver protocol

From: Derek Price
Subject: Re: FAQ-O-Matic pserver protocol
Date: Tue, 22 Feb 2005 16:44:38 -0500
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hash: SHA1

Brian Murphy wrote:

| Derek Price wrote:
|> Larry Jones wrote:
|> | Guus Leeuw jr. writes: | |> I take this as a veto for no
|> switches, but merely "cvs passwd" |> which would run only: a) if
|> pserver protocol b) the user in |> questo is listed in
|> CVSROOT/passwd on the pserver | | | I don't even like the idea of
|> doing that, but I won't veto it if | Derek and Mark think it's a
|> good idea.
|> Given the security deficiencies already inherent in the pserver
|> protocol, I can't see much harm in allowing passwords to be
|> changed via a CVS interface.  Requiring a user to type perl in on
|> the shell command line to change a CVS password doesn't seem to
|> me to add much additional security when the passwords are already
|> so easily compromised.  Might as well allow users who have
|> already decided pserver is secure enough for them the convenience
|> of a passwd interface.
|> Hrm.  Then again, the more I consider the implications of a `cvs
|> passwd' command, the less appealing it sounds.  Firstly, in the
|> recommended pserver configuration, if you fail to heed all the
|> dire warnings we provide about pserver in the first place, the
|> CVS team recommends that the CVSROOT module only be writable by
|> members of some cvs admin group, perhaps `cvsadmin', since
|> otherwise anyone could check in a CVSROOT/passwd file, add it to
|> CVSROOT/checkoutlist, and overwrite your passwd file, mapping
|> their account to any user on the system that they wished, other
|> than root.
|> To work around this in such a way as to allow any user to change
|> their own password, a few possible solutions come to mind.  The
|> cvs pserver would need to either keep root privileges longer than
|> it currently does, an option which is definitely out or,
|> alternatively, perhaps a second `cvspasswd' executable with
|> setgid cvsadmin privileges could be installed.  This sounds
|> slightly more secure, but still opens the possibility of new
|> weaknesses in the `cvspasswd' executable.
|> Perhaps some reasonable compromise could be reached, possibly
|> involving relocation of the CVS passwd file into /etc/cvs/ or
|> somesuch as has been suggested in the past, but most of what I
|> can come up with still involves the potentially dangerous setgid
|> executable.
|> The stated position of the CVS team has been to recommend using
|> some sort of :ext:/ssh access combination using system userids
|> when security is a concern.  This is an acknowledgement that CVS
|> gets few security audits and it is best to rely on tools that do
|> get thorough security audits for CVS access.  This also saves on
|> the time of the CVS maintainers by allowing us to leverage
|> existing tools where security is concerned.
|> I am still willing to discuss this matter, particularly because
|> my personal design philosophy tends to favor new features as
|> progress, with faith that the problems in a new design will be
|> discovered and solved later, but, at the risk of sounding
|> stifiling, the potential for new security issues arising in the
|> already flawed pserver design is real and I think these issues
|> need to be addressed before anything like this should be adopted.
|> Then again, perhaps the right approach would be to allow the
|> passwd command but continue to recommend clamping down permisions
|> on CVSROOT such that it can't be used.  This does sounds like a
|> contradictory position, though, and might help mislead naive and
|> beginning users.  I guess I'm with Larry, at least until these
|> issues are satisfactorily addressed.
| I have plans to impliment pserver with ssl support, it doesn't seem
|  too awful. Would there be any takers?

I would definitely favor pserver with SSL support as an improvement
over vanilla pserver.  If you do implement this, please see what you
can do about remaining compatible with CVSNT's SSL pserver mode

This would not change the `cvs passwd' command issues, however.  A
secure CVSROOT dir (which is necessary to prevent just anybody from
overwriting the CVSROOT/passwd file as things stand) still either
prevents `cvs passwd' from running or opens another potential security
hole.  I might be interested in seeing the setgid `cvspasswd'
executable, though.  Such a beast might be small enough to make
auditing fairly easy and should require few changes once it stabilizes.


Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


reply via email to

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