On Thu, Aug 10, 2000 at 01:44:54PM -0400, Greg A. Woods wrote:
> You haven't shown that at all, and indeed you haven't calculated your
> risks based on the likely threats.
Yes I have. That's what I just did.
> Indeed if your server contains only your repository, and especially if
> you've stripped it of unecessary tools, the only real risk is directly
> with your repository itself -- i.e. right where you propose to lock
> people in.
Think please.
They have nothing to attack in there, so they don't break root. Since
they don't break root:
> Unfortunately with cvspserver you've no accountability because now any
> authorised "user" will be able to use any of the many available hacks to
> compromise the identity of any other "user" and then even blatantly
> spoof changes as that other user.
They can't do this. Any change will be done under their own uid, and
since they can't break root, they can't change their uid.
> Also since this is an "open source" project the bigger and more complex
> it becomes, and the more developers you get working on it, the easier it
> will be for someone to covertly insert changes
The bigger it becomes the more people there will be reading the diffs
and the more difficult it will become to install covert changes. Duh.
> Furthermore since you're proposing not just an anonymous read-only
> server, but instead a full-fledged repository with commit access, you've
> complicated your chroot configuration by at least an order of magnitude,
> and maybe more if your users demand fancy CVSROOT/*info hooks.
They don't get write permission to CVSROOT/*info files.
> So, tell me again how you think a chrooted cvspserver eliminates more
> risk than an unchrooted SSH solution.
Give me a general shell on your machine and I'll break root within a
month or so. I'll just race you every time an exploit is posted on
bugtraq or rootshell.org--you have to win every race, I only have
to win once.
By locking the attacker in the repository I deny them the chance to
upgrade theis uid to the root user. Since they can't become root they
are only able to modify the files that they have permission to modify.
Right there that limits the damage they can do to a subset of the
repository. Secondly, they will leave a trail behind under their uid
so I'll know which account to delete and which files to fix.
With your unchrooted SSH solution you are effectively giving a root
shell to every one of those connected clients because:
1) given CVS access you can get a shell if you want it
2) given a shell on the root of the system you can run every
root shell exploit you can find, and you WILL get a root shell
sooner or later
It's just a matter of time. Your solution they get a root shell and
can instrument your kernel and cover their tracks. My solution they
get contained to a small number of files and I detect it.
> that but with the SSH solution you still have the opportunity to use
> chroot, and without even the risk of ever running CVS as root!
Yes, and to have ANY security at all you *have* to chroot and you
have to use real unix userids. That's true for the ssh solution just
as much as it's true for the pserver.
> Yes you still do have to find some basis in the real world for the trust
> you grant to your developers, and with SSH you have to ensure they
> understand that your security policy requires that they keep their
> client machines secure too.
That sounds like a huge barrier to development, and a barrier that I
don't need to erect given that I can recover from a breach so easily.
Justin
