Secure chroot Barrier

From Linux-VServer

Revision as of 12:26, 15 September 2009 by 193.231.72.8 (Talk)

Jump to: navigation, search

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.

doors.txt;10;15

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:

# setattr --barrier /vservers
# showattr /vservers
---Bui- /vservers
---bui- /vservers/pasat

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:

cd -P /etc/vservers/<guest>/vdir; setattr --barrier ..

Please note that it's important to set the barrier against ".." inside /path/to/guest/

(note: ---Bui- barrier set, ---bui- barrier available and not set)

Personal tools