Chroot is not a container
Every Linux sysadmin is familar with the chroot command. It has been used for decades to install a “system within a system”. At first glance it looks similar to what containers do nowadays. But that is a common misconception and can be dangerous.
Whether it is testing a program with a different set of libraries, using binaries from a different distro or testing if a new version of a program has that bug fixed. Chroot environments have been very useful to sysadmins and they still are. In the past I made extensive use of that technique. When containers became popular I thought: “O well that is just like chroot with some more features added”. That misconception was strengthened by people around me who had the same belief.
Luckily we did not go out in the wild with our false beliefs. But it is still common among webhosters that chroot environments are used as user environments (also known as chroot jail). When it comes to those techniques we first have to understand what is going on under the hood. Otherwise things can go horribly wrong.
SSH has an option to “lock in” users in their own chroot environment. That feature is commonly used by webhosters to allow customers to log in to a shared hosting server and have them locked in to their “personal space”.
Chroot does what its name suggests: It changes the root path of a process. Nothing more. Let us check how that looks like to the Kernel:
chroot /root/chroot_env
echo $$
11532
From “outside” the chroot we can see where our root path points to
ls -dl /proc/11532/root
lrwxrwxrwx 1 root root 0 Jun 5 11:08 /proc/11532/root -> /root/chroot_env
It may look safe and one might be tempted now to give a user root permissions inside his chroot “jail”. If he can not go beyond that path, what could go wrong then? Actually the Kernel does not know anything about chroot “environments”. Our security relies solely on the fact that we changed the root path. There is no guarantee that a user within the chroot jail can not change the root path to something else.
For instance if /proc is mounted he could do
nsenter --mount=/proc/self/ns/mnt
Now we have a root user on our system outside of his chroot jail.
A chroot is not a container. Not even a very simple one. Containers use Namespaces while chroot only changes the root directory of a process. A variety of webhosters got their servers hacked due to insecure “chroot jails”.
Security is never optional. It is a prerequisite. But in order to make our systems secure we have to understand what they are actually doing.
In further blog posts I am going to explain what namespaces and capabilities are and we dig a little deeper on this.
