[ On Thursday, August 10, 2000 at 21:24:24 (-0700), Paul Sander wrote: ]
> Subject: Re: cvspserver has no security to start with....
>
> First, a question: How would you get this chroot wrapper to work? You
> stated yourself that when using chroot, you must include the entire
> functionality of the envionment into the program that sets up the environment.
> You claimed in the strongest possible terms that placing executable files
> within the chroot environment was evil, and yet you must have something for
> the wrapper to execute after the chroot has been completed. You also stated
> in the strongest possible terms that the thing that does the chrooting must
> be as simple as possible, so as to provide most secure target for attack.
> There seems to be a paradox in here somewhere, and I'd like to know how you
> would propose to clear that up.
This is partly why it's even harder to set up a chroot() environment
safely and successfully than it is to write a setuid program.
A chroot wrapper will obviously require the CVS binary to live within
the new root subdirectory (and of course you've linked it statically so
that it doesn't require /usr/libexec/ld.so and a bunch of libraries
too! ;-).
Even if you don't use a wrapper you'll probably still need /bin/sh and a
few other simple tools in your new root too, especially if you want to
implement any *info scripts to do simple things like e-mailing commit
messages and such.
CVS is probably harder to chroot successfully, even with a wrapper,
while maintaining a reasonable level of functionality, than the Postfix
mailer was, and if you go and look at the way Wietse had to work at
chrooting Postfix I think you'll see just how much harder it'll be to
make CVS work safely.
In the end it is almost always smarter and safer to design a CVS server
with the inevitability of shell access in mind and to simply do as
SourceForge have done and to completely remove things from the system
that are not necessary *or* could be used maliciously.
> Second, a statement: Greg, you have a history of assuming that everyone's
> requirements precisely match your own, even if they don't know it.
Don't be an idiot Paul. Read what I've written and hopefully you'll see
that I've been explicitly dealing with Justins exact requirements (even
though he's tried to use faulty logic to suggest that I've ignored them
or otherwise misunderstood them).
Justin's basic requirements are extremely similar to those of a service
like SourceForge (perhaps even with the need for handling multiple
repositories, though he's been rather cagey in defining that need). He
(and perhaps you) would do well to learn from their very good example!
Just as there continue to be very educated and brilliant people who fail
to see why it's extremely dangerous to use plain POP or IMAP to a remote
server (but who would never any more use telnet!), there will continue
to be people who think that they can use cvspserver on the Internet.
Sometimes not even a vast amount of logic will convince them of the
error of their ways. What's very sad about this particular case is that
an almost free solution which solves all the issues in one simple swipe
exists and is easily usable by everyone involved. However still people
resist even beneficial change and continue to do dangerous and
unnecessary things. Bad habits die hard.
> I happen to believe that a chroot capability has value when protecting a
> repository regardless of how access is granted. The reason for this is
> that, when done right, it offers a smaller and more controllable (for me)
> target for the attacker. Never mind that it can't prevent or deflect all
> attacks; nothing can. But it is one more weapon in the arsenal of the good
> guys, and you have no valid reason to try to defeat it (provided it's
> supplied as an option).
In general for a simple service you would be right. In this case
however you're already leaning against the sharp double edge of the tool
and it is going to cut deep. There's no sense in misusing an offensive
(in both sense of that word, all puns intended) weapon that'll cause
more self-injury than benefit.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
