Chroot Jailing

kuniga.me > NP-Incompleteness > Chroot Jailing

# Chroot Jailing

19 Apr 2021

In this post we’ll study how to use the utlity chroot to create a jailed environment. We’ll also cover some security holes with this approach.

## A Simple Chroot Environment

The chroot command can be used to redefine the filesystem tree root as a new directory [1]. If we want a directory, say $HOME/root/, to be our new root, we can start a bash shell as: This will fail with: The problem is that because $HOME/root/ is empty, there are no binaries available, so we won’t be able to do much.

We can use a simple Bash script to copy the binaries and their dependencies to the new root directory.

setup.sh:

This adds /bin/bash, /bin/ls, /bin/mkdir and their dependencies to the chroot environment. We can now do:

and in there, inspect the root directory:

note we can’t go beyond that:

It’s worth noting that chroot does not clone the subtree under the new root in any way. chroot seems to only impose restrictions on accesses above the new root.

We can verify that by creating a new directory inside the jailed environment:

If we exit the chroot (e.g. with ctrl+d) and return to the original process, we’ll see the directory is still in $HOME/root/. ## Escaping chroot It’s possible to “escape” from a chrooted environment if we have root access and a C binary smuggled in. [2] provides the following code (comments added): escape.c: The exploit seems to rely on a behavior of chroot which removes whatever restrictions from the current chroot environment once a new one is created, so if we have a reference to the directory from the first chroot, it’s possible to climb up to the root directory of the original process. Before doing the chroot, we compile and add the binary to the chroot target directory: Inside the chroot: which should display the contents from the original process. ## Chroot for non-root By default, the chroot process has root privileges, but it’s possible to start it as a specific user and group, so that we restrict what operations can be performed inside the chroot. For example, if test_user is a user we want make a chroot to for, we can do: The problem is that since the owner of $HOME/root/ is not test_user, they won’t be able to do anything. We can create a home folder for them:

setup.sh:

We then generate the escape binary in the new home:

Inside the chroot:

Since chroot requires root privileges, they won’t be able to break out of the jail using the escape binary, so ls should still show the jailed directories.

## CAP_SYS_CHROOT capability

There’s a more granular permission model than root which is called capabilities. It’s possible to grant capabilities to binaries so they can perform operations even without root privileges.

One of them is the ability to run chroot, the CAP_SYS_CHROOT capability. We can add it to our smuggled binary.

setup.sh:

Now test_user we’ll be able to escape the jail even without root privileges.

This makes it hard to detect if there’s a vulnerability inside a chroot environment. Hence it seems to be a general recommendation to not rely on chroot for security purposes [3].

## Code

The full code for escape.c and setup.sh are available on Github.

## References

• [1] Wikipedia - Chroot
• [2] Escaping a chroot jail/1
• [3] Unix & Linux: chroot “jail” - what is it and how do I use it?