What is this "chroot" thing anyway, and more importantly, what purpose does it serve? Chroot is a Unix system call that re-maps the application's / (root) directory and further restricts the program to access only files in that directory and its children -- file access outside the chrooted environment is restricted. xChroot is available in all major Unix OSs.
As a result, chroot greatly enhances the security for the system. It creates a virtual sandbox inside of which the program operates. Should a vulnerability exist in the program, such that an attacker can gain file system access, he would only be able to access files inside the sandbox -- the rest of the system would remain inaccessable. He would have no access to your system /etc/passwd file, for instance. Two minor details: 1) prior to chrooting, call chdir (change directory) to the chroot directory (e.g. /var/chroot or somesuch), and 2) chroot must be followed immediately by a chdir call to '/' therefore ensuring the application is in the correct directory when it proceeds. To fail in either of these risks implementation specific side effects whereby other files outside the chroot could be available to the chrooted application.
Note that chroot is *not* equivalent to secure. If the system is running unpatched, chroot will only address the application using it while other vulnerabilities remain. If a chrooted program has a file handle open before the chroot call is invoked, that file handle remains open
Another situation is raw file system access. If a hacker obtains root access inside the sandbox and gains access to a raw disk device you architecturally placed inside the chroot structure , he has a link to the entire file system. If inode #0 is outside of the sandbox, he has a ticket to leave and can gain access to any file on that file system. This should be taken into account when considering loop-back mounts in to the sandbox, for example.
In conclusion, to chroot is typically better than not to chroot.
About the authors
John Stewart, IT consultant and Dave Kensiski, engineering development manager for Cable & Wireless, are also SANS Institute instructors. Content from this tip was extracted from their SANS instruction manual on "Web Site Security."
This was first published in June 2002