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 across the chroot and could potentially become a gateway
out of the sandbox. Of course, that presumes that a vulnerability
exists that can exploit the file handle; Care must still be taken.
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."
