On Thu, Aug 10, 2000 at 02:10:12AM -0400, Greg A. Woods wrote:
> > My scheme is weak on prevention because it uses pserver, but it is very
> > strong on recovery. Even an ssh scheme should have a strong recovery
> > capability to be secure, and I think that means using chroot (or better
> > yet, jail(2) on FreeBSD).
>
> You cannot have accountability with cvspserver, at least not without
> voiding your warranty and running CVS as root for a bit....
I personally estimate my own risks as being like this:
90%: I give a password to someone who turns out to be nasty and
they try to do something unpleasant to my archive
8%: Someone sniffs a CVS password somewhere
2%: Someone finds a buffer overflow in the code that runs as root
The reason why authenticated users represent 90% of my risk is that
people who might at some point have a motive to attack me have a good
chance of being in that group: maybe people who used to use my product
but now hate it for some reason; or people who used to use my product
but are now working on a fork or on a competing version; or maybe just
existing competitors who are pretending to be friendly.
I don't see the password sniffing as probable because it's simply not
all that interesting to attack. Most crackers are looking for a box where
they can get root privileges, and attacking my CVS repository by sniffing
passwords is pretty much guaranteed not to provide that. And it's very
unlikely that the people who might want to target me would also happen
to be on my upstream bandwidth. Possible, but unlikely.
The buffer overflow I list as being 2% of the risk. I don't think it
is all that likely to happen because there is just not a lot to exploit
in the pserver code. I'd say it represents 0.02% of the likely attacks,
but since an attack yields a root shell the risk is a hundred times
larger, so maybe 2%.
Obviously I'm making these numbers up off the top of my head and they
are not in any way scientific. They're just my rough estimates which
guide me in my efforts to reduce risk and help me decide which trade
offs are worth making.
Since I think 90% of my risk comes from authorized users I have taken
several steps to reduce that risk:
1) ACL. A lot of people simply can't write to most of the repository.
2) chroot. Even the people who can aren't able to escape the repository
3) diffs. If you do change something in the repository, I am watching, and
I look at all the changes to see who did what. There are other people
watching too.
4) lots of redundant backups and copies of my code out there, so that
i will always be able to revert to something if I have to
Having a chrooted pserver actually eliminates far more risk than a
non-chrooted ssh solution would. The ssh solution would substantially
improve authentication issues but would do nothing to reduce the 90%
of my risk that concerns me most.
Having a similar scheme but authenticated with some kind of challenge
response mechanism, such as SSL/SSH or some kind of modified pserver,
would knock off the next 8% of my risk. Enough that it's worth doing
some day, but not enough that it's a high priority for me.
As for the 2% risk of buffer overflows in the code running as root: well
I'm not just that bothered about it. If it ever does happen I will go in
and fix the buffer overflow and it won't happen again. It's just not one
of my top risks.
Justin
