Abusing chroot() for security

It is often suggested that people lock programs into a chrooted environment. A heated discussion about using chroot() for security purposes came up this week on the Linux Kernel mailing list (as reported on KernelTrap), with a quote from Alan Cox summarizing the backlash against using chroot() in this way:

chroot is not and never has been a security tool. People have built things based upon the properties of chroot but extended (BSD jails, Linux vserver) but they are quite different.

Adrian Bunk (current Linux 2.6 maintainer) even went so far as to say:

incompetent people implementing security solutions are a real problem.

Alan’s suggestions are worthy of consideration for security. BSD jails should always be used wherever they are available, as they are designed for this purpose. However, BSD jails are not normally available on Linux, though there are alternatives like the Linux vserver.

There was discussion about how easy it was for the root user to escape a chroot environment. It comes to a total of three steps:

1. Create a subdirectory within the environment.
2. Do a chroot to that subdirectory (while remaining outside of that directory).
3. Change directories at will.

The basic premise is that the chroot call maintains a single directory as the root (”/”) and that it will only prevent a user from moving from inside the environment to outside. If the user is already outside of that environment, then the containment does not happen. If the chroot call is made a second time, then it overwrites the original value of “/” with the new one for the current user (at least until the chroot() is exited).

So for serious security work, perhaps one should reconsider the use of chroot as Alan suggests.