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.
chroot command can be used to redefine the filesystem tree root as a new directory . 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.
/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
It’s possible to “escape” from a
chrooted environment if we have root access and a C binary smuggled in.  provides the following code (comments added):
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.
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:
We then generate the
escape binary in the new home:
Inside the chroot:
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.
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
CAP_SYS_CHROOT capability. We can add it to our smuggled binary.
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 .