[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RES: cvs watch add
Mark D. Baushke
Re: RES: cvs watch add
Mon, 10 May 2004 13:05:17 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Marcelo Carvalho Fernandes <address@hidden> writes:
> Thanks to Mark and Larry. I'm using 1.11.2. I saw the changes from
> 1.11.2 to 1.11.3 and It was fixed in 1.11.3.
Yup. You probably want to upgrade to the latest version of cvs if you
can take the time to do it.
> Mark, why avoid pserver ?
I do not believe it is secure to have cvs do any local
authentication/authorization or to ever run as root under any
If cvs is ever run as root, there is another vector for possible root
compromise on your machine. The cvs application was not written from
scratch with any useful security model in it and it does not have
the best track record for being secure (witness recent patches to
prevent security exploits).
Also, if the network path to your :pserver: server host is not secure,
the password is traveling over the network in a trivially encoded format
that may be used to compromise the account leading to the possility of
an audit trail that has been forged.
> What should I have to use ? Kerberos ?
I favor use of an external authentication mechanism such as :ext: via
ssh. This allows the ssh server to perform the authentication which it
does well and the filesystem to grant the authorization for a given
External authenticators should be small and easy to audit from a
security point of view. There are too many exceptions in cvs for it
to be easy to do a security audit of it.
That said, I have not even tried to do an audit of either the kserver or
gssapi interfaces in cvs myself. I suspect that either of them is likely
to be more 'secure' than 'pserver' in the sense of being vulnerable to
network snooping. However, without a security expert doing an
evaluation, I would not like to bet money on it. If you consider your
source repository to have economic value, do not use any method of
remote authentication that relies on cvs making any of the
authentication/authorization decisions or you are placing a bet without
a good understanding of the potential risks.
Being pragmatic, I don't mind folks using pserver in their own
environments if they understand the risks and lack of guarantees. There
are probably even limited scope and highly controlled environments where
pserver might be a reasonable solution, but I have concerns whenever
they are used over the Internet directly.
So, I believe that at least some folks find :pserver: access mechanisms
are just the right kind of thing for their purposes and I wish them well.
For example, I did not vote against the recent introduction of a PAM
module for the feature branch of the cvshome.org version of cvs.
I do not by any stretch consider that cvs is secure enough to run in
:pserver: mode for any of my own repositories.
If anyone is interested in writing a stand-alone :pserver: proxy which
could be audited easily and also used to run 'cvs server' securely, I
would not have any problem at all in seeing :pserver: ripped out of cvs
in favor of that approach. If you like the model, you could look at how
privilege separation works in many of the OpenBSD daemons and see what
it would take to replace the :pserver: feature in cvs with something
more secure... not that I believe it can actually be done, but I would
not mind being proven wrong.
I hope this explains my "I try to avoice :pserver: when possible"
comment in clear terms.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
-----END PGP SIGNATURE-----