On Sat, Aug 05, 2000 at 01:50:47AM -0600, Tobias Weingartner wrote:
> 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...
That's great. But it's effectively vapourware. I need a solution *now*.
> > 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.
So, those companies don't have to use the --chroot flag. They can use the
ssh mode, this doesn't affect them at all and they are completely irrelevant
to this discussion.
I am in the business of making my source code available to as many people
as I possibly can. My CVS server is like my public webserver: it lives
outside my firewall and the more people who have access to it the better.
I still need it to be moderately secure.
> 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.
Simple logic:
1) I need ACLs
2) I need pserver
3) So I have no choice but to run pserver as root
4) I would like to have moderate security on this pserver
5) So I have no choice but to fix it
There aren't any choices here. I've been waiting two years for the CVS
community to fix this problem and it hasn't happened yet. I can't wait
another two years. I need to fix this *now*.
> 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.
The effect of this check from an auditing point of view is that all you
have to audit is the pserver authentication code. After that, root
privileges are *guaranteed* to be dropped, and you're running inside a
chrooted environment.
The chroot becomes real security the moment you drop root privileges, and
prior to that it inconveniences an attacker--which is not real security, but
nevertheless reduces the number of times your machine gets broken into.
> 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?
Because it's vapourware. It doesn't really exist. So I can't use it. Blame
the clients if you want--it doesn't matter to me *why* it's vapourware, the
fact that it's vapourware stops me from using 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.
This patch is only relevant to those of us using pserver. If you attempt
to use it outside of pserver it exits with an error message. Since it
improves the security of any pserver it won't ever cause anyone grief.
The people you describe above won't be using this. They won't even have
their CVS repository on a publically accessible machine--it'll be behind
a firewall, so there's really no issue here. It's not relevant.
> 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*.
Well, without this patch I have *no* secure way to use CVS. That's the
final argument when it comes down to it. Yes, you ought to put in some
statements describing the actual risk of using a --chroot'd pserver on a
publically accessible box.
I don't need my pserver to be absolutely totally secure. I need it to be
in the same security ballpark as running a public httpd--and everyone knows
that is never absolutely secure either.
The --chroot patch puts pserver into that ballpark.
> 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".
So long as CVS continues to include 'pserver' we need this fix. When the
clients finally (if ever.. I've been waiting for this for two *years*)
implement some more secure access mode then maybe we can drop pserver
from CVS altogether and my patch will be obsoleted.
You're saying we shouldn't fix pserver today because in a few years
we will have some better way to use CVS.
Well that's nonsense--in a few years when we have a better way to use CVS
we can drop pserver completely, my patch included. Between now and then I
still have to run pserver, and I would like it to be moderately secure.
> Once this is done, pserver can go the way of the dodo-bird.
Agreed. But until then I need this patch. I can't put my project on hold
while I wait. Once these other vapourware ideas materialize I will happily
help rip pserver out of the CVS distribution.
But I still need this fixed *now*.
Justin
