On Sat, Aug 12, 2000 at 11:50:46AM -0400, Greg A. Woods wrote:
> 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! ;-).
You might wind up needing some libraries anyway on recent System V
unixes, such as Debian/GNU Linux or Solaris.
> CVS is probably harder to chroot successfully, even with a wrapper,
> while maintaining a reasonable level of functionality
The only tricky thing is email. In order to create functional chroot(2)
and jail(2) areas for programs like CVS (and others) I wrote a mailer
program called "portmail". It looks enough like sendmail that if you
install it as /usr/lib/sendmail (or wherever) programs like /bin/mail
will happily use it to send mail.
But instead of being a sendmail implementation (which would have to
be installed setuid) it delivers submitted mail by connecting to the
mail daemon on 127.0.0.1 (or another IP) and dropping off the mail.
This avoids having to install setuid binaries into the chroot, which
would weaken the protection offered by chroot a lot. If you install a
setuid binary and an attacker finds a way to exploit it then they
can break out of the chroot. So don't put any setuid binaries in.
> 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.
No, this is dumber and weaker and quite a bit more difficult to do than
creating a secure chroot(2) environment. First, it offers the attacker a
chance to break the root account. Second, the box would be so non-standard
that it would be quite a lot of manual work to get it all set up.
Third, are you seriously suggesting that an admin who does not know
enough to be able to set up a secure chroot(2) is going to know enough
to secure a standard Unix distribution against shell accounts??!?!
The only way to set up a secure environment is to start with nothing and
then add only the things you need. This is how you create a chroot(2)
environment, and it's a lot less work than creating an entire Unix
distribution.
> > 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.
Most CVS installations don't really need to have much in the chroot. Most
of the time all you need is a way to email out commit messages. I have
a solution to that which perhaps I should post.
Maybe I should post a package for chroot(2)'ing a pserver so that other
people, with less experience, don't have to do any thinking to set it
up in a secure(*) fashion.
Justin
(*) meaning that an attacker might be able to break into your repository
and do unauthenticated stuff, but they won't be able to break out of
the repository into the system, or gain access to UID's that you
did not intend them to access (ie: that were not assigned to pserver).
