chroot exercise

It's well know that the linux filesystem has a root directory. Also but  little known, each process keeps it's own root directory.

The root directory of a process is just the name of some directory in the filesystem. That name is stored within the process. So the process's root directory, unlike the filesystem's, is virtual rather than physical. A process's root directory has real import however. When the operating system interprets filenames that appear in the process's code, it does so relative to whatever physical directory the process names as its root. For example, if a process has /home/joe as its root directory, and asks to open a file named /etc/passwd, the OS composes the name "/home/joe/etc/passwd" and that's where it looks for the file in the physical filesystem. It will not find, and won't look for, the filesystem's /etc/passwd. The effect is to blinder the process to any part of the physical filesystem except the part under the process's root. Since new processes inherit their parent process's root directory, any spawned processes will be similarly blind. The security implication is protection of most of the filesystem from the code in the process.

Most processes' root directories are /, the filesystem's root. They are one in the same. The process has visibility over the entire filesystem. When you launch a process, you can tell it another directory to adopt and record as its root. The chroot command does this. The syntax is:

  chroot  <root for process>  <command to run>

Suppose you want to run program ls. Running a program entails going to the filesystem to get the file that contains it (e.g., /bin/ls).

If you run normally, the shell uses its process root, which is the filesystem root, for the search. The filesystem as a whole becomes the frame of reference in which to look for /bin/ls. If you run with chroot as shown, the /home/charlie directory becomes the frame of reference and starting point for the search. Beneath that, there is no bin/ls, hence the error message.

The exercise to perform

As user root, create a new user "charlie" and give him a password:

[root@CHANG ~]# useradd charlie
[root@CHANG ~]# passwd charlie
Changing password for user charlie.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Now log in as charlie to set up a "jail" directory under his home directory. We will make that directory become the effective root directory, from which to execute the date command. But the normal date command, because it lives at /bin/date outside the jail, won't be accessible. We'll have to put duplicate copies of both the date program itself, and any libraries it needs to call at runtime, within the jail so as to be available from there.

[charlie@CHANG ~]$ cd
[charlie@CHANG ~]$ mkdir jail
[charlie@CHANG ~]$ cd jail
[charlie@CHANG jail]$ pwd
/home/charlie/jail
[charlie@CHANG jail]$ mkdir bin lib

Move a copy of the executable file for the date command, which resides in /bin relative to the root directory, into an identical location (/home/charlie/jail/bin) relative to the jail.

[charlie@CHANG jail]$ cp   /bin/date  bin

Find out which shared libraries date needs, using the ldd command:

[charlie@CHANG jail]$ ldd bin/date
linux-gate.so.1 => (0x0046f000)
librt.so.1 => /lib/librt.so.1 (0x00186000)
libc.so.6 => /lib/libc.so.6 (0x00231000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00474000)
/lib/ld-linux.so.2 (0x0020f000)

Move copies of these libraries, which reside in /lib relative to the root directory, into an identical location (/home/charlie/jail/lib) relative to the jail.

[charlie@CHANG jail]$ cp   /lib/librt.so.1   lib
[charlie@CHANG jail]$ cp  /lib/libc.so.6   lib
[charlie@CHANG jail]$ cp   /lib/libpthread.so.0   lib
[charlie@CHANG jail]$ cp   /lib/ld-linux.so.2   lib

Now become the root user. Run the date command, but not in the normal way from the normal place. Instead run date through chroot, changing your filesystem base starting point (i.e., effective root directory) from the filesystem's physical root directory (/) to /home/charlie/jail instead. Run the copy of date that's in there, rather than the normal one (which is invisible/unavailable from in there).

[charlie@CHANG jail]$ su
Password:
[root@CHANG jail]# whoami
root
[root@CHANG jail]# pwd
/home/charlie/jail
[root@CHANG jail]#
[root@CHANG jail]# /usr/sbin/chroot   /home/charlie/jail   /bin/date
Thu Feb 16 14:00:25 UTC 2006

Now demonstrate the unavailability of normal commands from within the jail:

[root@CHANG jail]# /usr/sbin/chroot /home/charlie/jail /bin/ls
/usr/sbin/chroot: cannot run command `/bin/ls': No such file or directory

The ls executable file, named as "/bin/ls", is not found because the search is restricted within /home/charlie/jail and therefore seeks a nonexistent file /home/charlie/bin/ls. The existence of /bin/ls relative to the filesystem's physical root is immaterial because the "/bin/ls" reference in the chroot command line is not relative to the physical filesystem. Implicitly, it is talking about /home/charlie/jail/ls, not /bin/ls. The difference between running date, which worked, and ls, which didn't, is that you took the effort to place copies of the files for date in the places chroot would look for them.

Another indication of chroot's effect is the difference between the date command's output run normally and run from the chroot jail:

[root@CHANG jail]# /bin/date
Thu Feb 16 06:40:54 PST 2006
[root@CHANG jail]#
[root@CHANG jail]# /usr/sbin/chroot   /home/charlie/jail   /bin/date
Thu Feb 16 14:40:58 UTC 2006

The time is reported for different time zones. The time zone is dependent on the presence of certain configuration files. They are present in the first scenario, but not in the second because of chroot.