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 com plains 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 ker nel 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 com mands, 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.