You have to use a script or application that you don’t trust.

Consider placing it in a so-called chroot jail. The chroot command changes the root directory of the current process to the directory you specify, then returns a shell or exec’s a given command. That has the effect of placing the process, and thus the program, into a jail from which it theoretically can’t escape to the parent directory. So if that application is compromised or otherwise does something malicious, it can only affect the small portion of the file system you restricted it to. In conjunction with running as a user with very limited rights, this is a very useful layer of security to add.

Unfortunately, covering all the details of chroot is beyond the scope of this recipe, since it would probably require a whole separate book. We present it here to promote awareness of the functionality.

So why doesn’t everything run in chroot jails? Because many applications need to interact with other applications, files, directories, or sockets all over the file system. That’s the tricky part about using chroot jails; the application can’t see outside of its walls, so everything it needs must be inside those walls. The more complicated the application, the more difficult it is to run in a jail.

Some applications that must inherently be exposed to the Internet, such as DNS (e.g., BIND), web, and mail (e.g., Postfix) servers, may be configured to run in chroot jails with varying degrees of difficulty. See the documentation for the distribution and specific applications you are running for details.

Another interesting use of chroot is during system recovery. Once you have booted from a Live CD and mounted the root file system on your hard drive, you may need to run a tool such as Lilo or Grub which, depending on your configuration, might need to believe it’s really running onto the damaged system. If the Live CD and the installed system are not too different, you can usually chroot into the mount point of the damaged system and fix it. That works because all the tools, libraries, configuration files, and devices already exist in the jail, since they really are a complete (if not quite working) system. You might have to experiment with your $PATH in order to find things you need once you’ve chrooted though (that’s an aspect of the “if the Live CD and the installed system are not too different” caveat).

On a related note, the NSA’s Security Enhanced Linux (SELinux) implementation of Mandatory Access Controls (MAC) may be of interest. MAC provides a very granular way to specify at a system level what is and is not allowed, and how various components of the system may interact. The granular definition is called a security policy and it has a similar effect to a jail, in that a given application or process can do only what the policy allows it to do.

Red Hat Linux has incorporated SELinux into its enterprise product. Novell’s SUSE product has a similar MAC implementation called AppArmor, and there are similar implementations for Solaris, BSD, and OS X.