In the world of information security, you have to assume that hackers will get into your network. Whether using a zero-day exploit, sending malicious emails to your employees or taking advantage of poor coding in use on your webpage, attackers are coming for you. Your job as an administrator is to make it as difficult as possible for an attacker to gain access as well as being able to detect and mitigate an attack after it occurs. This is why practicing “defense in-depth” must be an essential part of your everyday thought process. When deploying new services, devices, or applications, you should think to yourself: “If this were compromised, how could I mitigate the risk of an attacker advancing further into my network?” In come chroot jails.
Chroot is an operation that made its first debut in BSD 4.2 and is found in just about every Unix or Linux based operating system today. The primary uses of chroot are for testing, compatibility, and privilege separation purposes by setting the root path of a process to a specified directory, thereby limiting the exposure of your system to that process. You may have used chroot to get back into your systems after forgetting your root password. For example, if you chroot Apache’s httpd process into /opt/httpdjail/, httpd will consider the /opt/httpdjail/ directory of the main file system to be the real / and won’t be able to “see” any directories above httpjail/. The process of using chroot to control the root path of a process can also be referred to as “sandboxing.”
Let’s say you’re running an Apache web server that is fully patched. Unfortunately, an attacker has developed a zero day exploit for Apache and is able to compromise the httpd service. As bad as this already is, it can get worse. At this point, the attacker could explore the system, and possibly try to connect to other machines within your environment. If you have the Apache service configured in a chroot jail, the attacker won’t get very far. A correctly configured chroot jail will have only the files and libraries needed to run the service, all of which would be set to minimum privileges. This will effectively prevent the attacker from exploring the file system outside of the jailed directory or from executing binaries that are not stored within the jail.
The first step in configuring a chroot jail is creating the file structure within a single directory which is owned by root:root. Next, you will have to copy all of the dependencies into the jail. An easy way to locate the dependencies of a binary file is to use the ldd command. This can be more complex when dealing with large applications such as Apache or BIND, as opposed to just wanting to set up a simple shell. The next step is to restrict file permissions on the files in the jail as much as possible. Once everything is set up and ready to go, you will need to manually chdir to the jailed directory, then chroot into the new environment. Last but not least, you will need gracefully release permissions by appropriately setting the UID of the executable to a non-root user.
Important things to remember when setting up a chroot jail are:
- Do not run anything in the jail as root
- If it serves no purpose, leave it out of the jail
- Set permissions as low as possible
- Set owner of all files to root when possible
Configuring chroot jails is easier now than it has been in the past. Using packages such as mod_chroot for use with Apache, or Jailkit, an open-source project with a handful of utilities, can make configuring a chroot jail much more efficient and even automated in some cases.
I know what you’re thinking. Nothing is 100% secure, there must be a way to break out of the jail. In fact, you are correct. When configured improperly, a chroot jail can be escaped by a variety of methods, almost all of which revolve around the running processes inside the jail as root. Avoid this costly mistake, and it will be much more difficult for an attacker to break out of the jail. In summary, if you’re looking for a way to increase security around your applications or need to give a user restricted access to a machine without impending on the functionality, chroot jails are the way to go on a *nix based system.