If you keep all the guests in one filesystem, setting the barrier on /vservers is enough, otherwise it should be repeated for each mount point.

+

If you keep all the guests in one mountpoint, setting the barrier on /vservers is enough, otherwise it should be repeated for each mount point.

If you want to be safe you may choose to just set the barrier for each individual guest, for example:

If you want to be safe you may choose to just set the barrier for each individual guest, for example:

Line 329:

Line 329:

''(note: <tt>---Bui-</tt> barrier set, <tt>---bui-</tt> barrier available and not set)''

''(note: <tt>---Bui-</tt> barrier set, <tt>---bui-</tt> barrier available and not set)''

+

+

[[Category:Documentation]]

Latest revision as of 20:00, 21 October 2011

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.

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.

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:

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:

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:

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: