Containing Intrusions in Apache - Tools of the chroot Trade (Page 3 of 4 )
Before you venture into chroot land you must become aware of several tools and techniques you will need to make things work and to troubleshoot problems when they appear. The general problem you will encounter is that programs do not expect to be run without full access to the filesystem. They assume certain files are present and they do not check error codes of system calls they assume always succeed. As a result, these programs fail without an error message. You must use diagnostic tools such as those described below to find out what has gone wrong.
Sample use of the chroot binary
The chroot binary takes a path to the new filesystem root as its first parameter and takes the name of another binary to run in that jail as its second parameter. First, we need to create the folder that will become the jail:
# mkdir /chroot
Then, we specify the jail (as the chroot first parameter) and try (and fail) to run a shell in the jail:
# chroot /chroot /bin/bash
chroot: /bin/bash: No such file or directory
The above command fails because chroot corners itself into the jail as its first action and attempts to run /bin/bash second. Since the jail contains nothing, chroot complains about being unable to find the binary to execute. Copy the shell into the jail and try (and fail) again:
# mkdir /chroot/bin
# cp /bin/bash /chroot/bin/bash
# chroot /chroot /bin/bash
chroot: /bin/bash: No such file or directory
How can that be when you just copied the shell into jail?
# ls -al /chroot/bin/bash
-rwxr-xr-x 1 root root 605504 Mar 28 14:23 /chroot/bin/bash
The bash shell is compiled to depend on several shared libraries, and the Linux kernel prints out the same error message whether the problem is that the target file does not exist or that any of the shared libraries it depends on do not exist. To move beyond this problem, we need the tool from the next section.
Using ldd to discover dependencies
The ldd tool—available by default on all Unix systems—prints shared library dependencies for a given binary. Most binaries are compiled to depend on shared libraries and will not work without them. Using ldd with the name of a binary (or another shared library) as the first parameter gives a list of files that must accompany the binary to work. Trying ldd on /bin/bash gives the following output:
# ldd /bin/bash
libtermcap.so.2 => /lib/libtermcap.so.2 (0x0088a000)
libdl.so.2 => /lib/libdl.so.2 (0x0060b000)
libc.so.6 => /lib/tls/libc.so.6 (0x004ac000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00494000)
Therefore, bash depends on four shared libraries. Create copies of these files in jail:
# mkdir /chroot/lib
# cp /lib/libtermcap.so.2 /chroot/lib
# cp /lib/libdl.so.2 /chroot/lib
# cp /lib/tls/libc.so.6 /chroot/lib
# cp /lib/ld-linux.so.2 /chroot/lib
The jailed execution of a bash shell will finally succeed:
# chroot /chroot /bin/bash
bash-2.05b#
You are rewarded with a working shell prompt. You will not be able to do much from it though. Though the shell works, none of the binaries you would normally use are available inside (ls, for example). You can only use the built-in shell commands, as can be seen in this example:
bash-2.05b# pwd
/
bash-2.05b# echo /*
/bin /lib
bash-2.05b# echo /bin/*
/bin/bash
bash-2.05b# echo /lib/*
/lib/ld-linux.so.2 /lib/libc.so.6
/lib/libdl.so.2 /lib/libtermcap.so.2
As the previous example demonstrates, from a jailed shell you can access a few files you explicitly copied into the jail and nothing else.
Next: Using strace to see inside processes >>
More Apache Articles
More By O'Reilly Media
|
 This article is excerpted from chapter two of Apache Security, written by Ivan Ristic (O'Reilly; ISBN: 0596007248). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 3 
