On Fri, Aug 11, 2000 at 02:29:39AM -0400, Greg A. Woods wrote:
> > They have nothing to attack in there, so they don't break root. Since
> > they don't break root:
>
> They don't need to break root -- they've already got write access to
> your one object of value!
No, they only have write access to small parts of it.
> Pulleeeeze! There is NO security in cvspserver! Any user can spoof any
> other user with only a very few "script-kiddie" class tools! Any third
> party can relatively quickly and easily spoof anyone too! Even worse
> it's not hard to spoof the server from the client's point of view too!
No, any other user cannot spoof any other user. Anyone on the pipe can
spoof anyone, which is subtly differen than what you say.
> I.e. there's zero accountability in cvspserver and without
> accountability you can throw all the other buzzwords you want around and
> you still have no security whatsoever.
There's zero accountability with ssh too. People just have to sound like
they're nice and competent developers and have an email address that works.
> Besides, nobody *needs* root access to crack a cvspserver system -- it's
> just that cvspserver, especially your hacked version with chroot() in
> it, requires that it be run as root and thus this only makes it more
> vulnerable -- i.e. you've taken an insecure C/S system and made it even
> less secure by introducing yet another unnecessary risk!
Round we go: it's more secure because it strictly limits what an attacker
can do.
> Also, remember what I said about spoofing the server? Well what if
> you've made the mistake of using the server in the same way as other
> clients to view code changes and do your audits? Can you guess why the
> cracker will want to spoof the server?
I use ssh to access the server. It's my clients who are using WinCVS :-)
> hmmm... i wonder what i can do when a privileged program runs an
> un-patched version of *BSD Mail.... now where did i put that suidperl
> exploit anyway -- it had the exact recipie i need! yes, there it is!
> give me a shell NOW you broken *info script!
And how are they going to do that, since *BSD Mail is not in the chroot?
There are *NO* setuid binaries in my chroot.
Aha, maybe no Greg sees the light.
> > 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.
>
> No, you won't. You'll only get an account if you explicitly promise
> *not* to try anything unauthorised.
OK, so the only difference between me and the person who is going to hack
root on your box is that I don't lie about my intentions.
> So, if you do mess about then I'll probably catch you at your tricks and
> hold you accountable for your promise of never trying to break root!
And how are you going to "hold me accountable for my promise", Greg? Are
you going to try and sue me? Send the police after me? What if it turns
out that really I am not "Justin Wells" but rather some script kiddie
pretending to be "Justin Wells", and in actual fact I live in Russia? How
are you going to hold me accountable then?
This is the internet, Greg. Nobody really knows who anybody else is. Sure,
we both live in Toronto and I could exchange some public key with you, but
that's not a general solution for a worldwide accessible repository.
It would be nice if use of PGP was widespread and the "web of trust"
actually existed and such... but it isn't and it doesn't so we're stuck.
> And in the hypothetical scenario where you work for me you'll be
> immediately dismissed and walked out the door by the security guard,
> never to return again.
Sure, all kinds of things work when you have the professional software
development shop training wheels attached to your CVS repository.
But now you're on the internet, and all this clap trap doesn't work. Now
you need real security, since all your authentication schemes don't really
amount to a hill of beans.
> > 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.
>
> You've said yourself that the system itself doesn't matter much to you.
But, being able to limit how much of the repository the attacker can access
does matter to me. And, if they are contained in the repository the real
victory is that they are not root: which means they can't do anything to
hide their tracks. So I can clean up after them--it helps with recovery
that I can stare in at them from the outside of the repository and see
what they are doing.
Furthermore, since binaries like "cvs" live outside of the repository they
can't install any automated attacks, etc.
There's a substantial advantage here and you can worm and wiggle all
you like and it won't go away.
You are the only one on this list who can't see the improvement offered
by the chroot. There are lots of people who may think pserver is too big
a risk to take, but other than you, they aren't arguing against chroot.
> > 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.
>
> Huh? that's totally meaningless. have you forgotten how cvspserver
> works again? it doesn't authenticate and authorise real unix users --
> it's concept of user-ids is completly orthogonal to system user-ids!
Stop equating security with authentication. I don't care what userid you
have, I want to limit the damage you can do.
> If you can't trust the developers you "hire" enough to be reasonably
> sure they won't mess about with a shell account on your central
> repository machine then you really shouldn't trust them to write code
> for you, regardless of whether you audit it carefuly or not!
Actually I start out by giving them very limited access to the repository
and let them work on fairly isolated stuff first, to prove their track
record to me. Over time I open up more and more of the repository to
them. But this has nothing to do with security, it has to do with
code quality.
Justin
