On Tue, Apr 02, 2002 at 01:51:55PM -0600, David Blevins wrote:
> For maximum security, run a chroot'ed cvs. I don't see any howto's on
> chroot'ing cvs specifically, but there is one on bind. The idea is
> the same, you should be able to figure out how to setup cvs to run the
> same way.
Chroot is a fairly simple concept. When you run chroot(8), you must be
root to do so.
shell# chroot <directory> <command>
If "command" is not supplied, chroot will try to run /bin/sh relative
to the directory you specified.
shell# chroot /tmp/chroot1
# actually runs /tmp/chroot1/bin/sh
However, when you're inside a chroot environment, you do not have access
to the parent directory. You are "trapped" at /tmp/chroot1 and are lead
to believe that it is the acutual root directory "/".
Here's where chroot gets a bit complicated. In order to run chroot
effectively, you need a few essential files and directories. For
example, you'll need /etc as well as /etc/resolv.conf, /etc/hosts,
/etc/networks, /etc/nsswitch, and /etc/passwd. If you wonder why you
sometimes see an "./etc" directory in let's say /var/lib/mydaemon, it's
probably because "mydaemon" can run in a chroot environment and the
basic files needed are located there.
Now, that's not the end of it. In order to run an application in a
chroot environment, it must have all the necessary libraries and utils
to run. Let's say the application uses shared libraries. You will need
the /lib directory and any libraries that the application needs, which
you can find with ldd(1). However, this only finds those library files
necessary for linking at compile time.
The application may use the dynamic load library functions to load
libraries at run-time. The only way to find these is to either read the
source code of the program or run a program like strace(1). With
strace, you can see all the system calls a program makes, including
fopen().
For this reason, it is sometimes easier to simply recompile the
application you wish to chroot as a static binary.
Now, let's say the application actually uses calls like system(), exec()
or fork(). You now need to know the names of child applications or
those that your target application depends upon. Maybe it needs a POSIX
shell, or perhaps ssh. Time to copy those apps and their dependancies
as well.
Building a chroot geol/jail can be a time consuming process, but it does
have its benefits. If an attacker does get "root" access from a
running, chroot'ed daemon, they simply get root in that chroot
environment. The damage to the system is minimal, being only that found
in the chroot environment.
There are ways to break out of a chroot geol, but at least the hurdles
are in place.
--
Chad Walstrom <chewie at wookimus.net> | a.k.a. ^chewie
http://www.wookimus.net/ | s.k.a. gunnarr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20020404/d8217b8d/attachment.pgp