Secure chroot Barrier

From Linux-VServer

The chroot system call changes the root directory of the current process. This directory will be used for pathnames beginning with /. The root directory is inherited by all children of the current process.

However several problems are known while using the chroot system call:

This call changes an ingredient in the pathname resolution process and does nothing else.

This call does not change the current working directory

This call does not close open file descriptors

These facts disclose several ways to break out of chroot, back to the original root. Some of these methods will be outlined on this page. Additionally we will discuss how a Linux-VServer kernel prevents these breakouts.

Contents

Breakout Methods

Using a temporary directory

Since the chroot system call does not change the current working directory, after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a 'chroot jail' using the following commands:

# mkdir foo
# chroot foo
# cd ..

This method is well known, and even documented in the chroot man page.

Using chdir("..") many times

The fact that the chroot system call does not change the current working directory allows to use the chdir system calls many times to get the old root. The following C program demonstrates how to use this method:

Using an open file descriptor

Since the chroot system call does not close open file descriptors, you can use these file descriptors pointing outside the chroot to escape. The following C program demonstrates how to use this method:

In fact, util-vserver uses this approach to obtain a file descriptor of a directory inside the guest file system root during startup, to secure mount operations (e.g. prevent symlink attacks pointing outside the guest root)

Transferring file descriptors with SCM_RIGHTS

Even if one tries to prevent the fchdir part in the above example by forbidding open directories at chroot time, it would still be possible to break out of the chroot jail. The 'solution' here is to transfer file desciptor using socket level control message with SCM_RIGHTS. The following program demonstrates this method:

Solution: Secure Barrier

While early Linux-VServer versions tried to fix this by "funny" methods, recent versions use a special marking, known as the chroot barrier, on the parent directory of each VPS to prevent unauthorized modification and escape from confinement. This barrier is implemented as a Filesystem Attribute and prevents a path_walk into a directory with enabled barrier.

Therefore it is important to set the barrier flag on your vserver base directory, for example:

(note: strictly speaking this is incorrect, instead one wants to do setattr --barrier /path/to/guest/.. for all guests, which can be quite different from the above, even for guests in /vservers *Bertl*)