On Saturday, August 5, Justin Wells wrote:
>
> I can't do that because I need to control access to portions of the
> repository using groups. I wish CVS had this capacity internally but
> it doesn't--I have to rely on Unix groups and that means I have to
> run CVS as root.
Huh!?! CVS does not need to run as root to get the "unix groups"
benefit. You simply have to create accounts on the machine, and
use something like the ssh transport in order to correctly utilize
this feature. Been that way since day one...
> Different groups of people own different parts of my CVS tree. Some
> people have more access than others. Some people have only anonymous
> access. Others can write to almost anything. If I shut these people
> out of my CVS archive on the grounds of it being "insecure" and them
> not being able to run CVS over "ssh", then I cut off valuable development
> resources that are worth a lot more to me than the security of one
> unimportant box.
Most companies in the business of selling their software would make
you eat that statement. In other words, that box would be their most
important asset (along with the coders)... Then again, you have to
know what your risks are, and what you are willing to live with.
At the current time, CVS does not do ACLs of any sort. You can hack
them up somewhat using commitinfo/etc, but true ACLs are not there.
IMHO, there are *lots* of other places and bugs in CVS that should get
fixed before somebody implements yet another ACL system to manage
protections. So far, the unix kernel has done this job quite well,
reusing that existing functionality is a better use of your resources.
> Chroot, when used properly, and on a good OS, is adequate for locking up
> a *non-root* process. It's true that if there is a flaw in the auth portion
> of the pserver request allowing someone to execute arbitrary code then
> they can escape from the chroot.
One of the main reasons why I believe that chroot() is a fundamentaly
flawed concept.
> However I feel my risk is substantially less than it was: the attack has
> to overcome the chroot(), and it is limited to the auth segment of the code.
> Theoretically possible yes. Practically much less likely to happen than
> the situation without this patch.
Hmm... without auditing the whole CVS source, *and* your scripts, I can
not for certain say that you are actually more secure. Maybe a little
more inconvenient, but inconvenience is hardly security.
> Unfortunately the way Unix is written there is no other way to gain
> access to setgid. If there were, my problem would be solved. If CVS
> had some other kind of group access control technology in it that
> would also solve my problem, but it doesn't.
A normal login to the machine will work just fine. /bin/login (or
whatever your platforms equivelant is) will actually do the setgid()
(and a host of other things) for you. Why not use it?
> The cost of a breakin here is minimal. It's on a machine running nothing
> important other than the CVS server. So the cost is that I have to
> reinstall the machine.
And restore source files from backup, and settle lawsuits should that
source you released last month actually contain some copyrighted M$
material, etc. Yeah, I'm playing the devil's advocate, but the thing
to realize with CVS is that it is being used in *many* different places.
> > In the end the only real solution is to ditch cvspserver completely and
> > revert to using the designed for external transport mechanisms that use
> > real system authentication and authorisation, such as SSH or whatever.
>
> Which is not supported by the majority of my CVS clients (who are
> external users outside my organization and I don't want to spend
> time on the phone with them helping them get WinCVS working with
> ssh, if WinCVS actually ever successfully works with ssh at all).
>
> I can't force them to switch to Unix, install loads of specialized
> software, or fix WinCVS so that it's ssh mode actually works. I do
> *have* to provide them with access to my CVS tree or my project will
> die--not an option.
Then that is a risk you take for yourself. I'm not sure that I'd like
to see the rest of the CVS community take that risk. Granted, your patch
of chroot() is of minimal risk. *However*, having that in the main
sources *will* signify to at least 30% of the CVS community that this
chroot() stuff is supported, and secure *all the time, by default*.
This of course if not true, but to support this argument, you have to
only look at the last several versions of the reserved-checkout,
exclusive-locking arguments that people have put forth with the quite
blatantly stated 'use at your own risk' feature in "cvs admin".
If the "feature" is there, no matter how bad or good, people will use
*and* abuse it. The use is good. The abuse comes back in the way of
bad publicity due to the clueless nature of 70% of the people that are
using something they do not understand. I believe that CVS can do
without that.
> CVS needs a general solution to this problem. What I did isn't ideal, in
> any sense, but it is about 1000 times better than doing nothing.
CVS does not need a general solution to this problem. The solution does
exist. It is called ssh access to the CVS repository. The problem is
that the clients have no such "general solution". I'd be quite pleased
if the maintainers of WinCVS, MacCVS, whateverCVS clients would be so
kind as to make their clients work with the ssh protocol. The code is
quite freely available, and this should be 100% workable and doable.
In other words, fix the real problem, don't patch the bloody sympthom.
Once this is done, pserver can go the way of the dodo-bird. (IMHO,
pserver is the same sort of hack that the chroot() stuff wants to solve.
I think it is quite stupid to put one hack on top of another, simply
to solve the first hack.)
> Here's the main problem:
>
> The CVS community has sat around gasping about this problem for a
> *very* long time now: years and years, and nothing whatever has
> been done about it. I was going to work on a fix before, but I ran
> into heavy flak from everyone on this list who was absolutely sure
> that "ssh" was the right way to go. Well ssh isn't the right way
> to go, and I say that based on the fact that 90% of my clients
> can't figure out how to get it work. A solution that doesn't work
> is no solution at all.
No, ssh *is* the right way to go. Not telnet, not rsh, not pserver,
not any sort of unauthenticated and encrypted (at least tamper-proof)
channel will do. You may have not been holed yet, but you will. It
is only a matter of time, statistically speaking.
The problem is the rather minimal implementation from the CVS client
community on the communication side of this "deal". I applaude them
for creating such diverse clients, I could never do so myself. I do
not applaude them for continuing the tradition of the 80's use of
antiquated authentication and integrity protocols. I believe that
such use is simply irresponsible and should not be tollerated.
As such, I ask (if it will help, I'll plead too) with the developers
of WinCVS/etc to integrate ssh support into their products. Steal
the code from www.openssh.com, munge it, change it, stuff it into
your CVS client.
> What CVS really needs is an external module which handles authentication,
> has support for ssl, performs the chroot/setgid on auth and then invokes
> the ordinary cvs to do the processing, and is short enough that it
> can be effectively audited. CVS doesn't have that, and my guess
> at this point is that it never will: in the meantime, my life goes
> on and I had to do something.
ssh is one such module, and the unix side of this equation has had this
for quite some time. I fail to see how a chroot() patch is going to
further the cause of a more secure network connection.
--Toby.
