To chroot or not to chroot

John Stewart and Dave Kensiski

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

    Requires Free Membership to View

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."

This was first published in June 2002

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.