Chroot-barrier
chroot-barrier[edit]
What is it?[edit]
As you might know, the default chroot implementation in Linux is not secure, there are well known ways to break out of a chroot. As the vservers reside in directories below the host system's root, we need a way to make sure that they cannot break out of their area, i.e. that they can't reach the host's or other vservers' areas. To achieve this, linux-vserver uses a marking known as the barrier.
How does it work?[edit]
really depends on the version, but basically it ensures that the vserver guest root can not pass a certain 'marked' directory with chroot().
the barrier either consists of a combination of certain attributes (i.e. flags and modes) or of a special flag, which is protected against modification from inside a vserver.
if you need more details, visit #vserver on OFTC and ask ...
How to use it?[edit]
Depends on which version of linux-vserver you're using.
<vserver-base-directory> is the directory in which the actual roots of your vservers are
(e.g. /vservers)
but for mounting/namespace/whatever reasons, it's better to specify it indirectly via <path-to-vserver>/..
(e.g. /vservers/myserver/..)
1.26+ (1.25 breaks some distros)[edit]
chmod 0000 <vserver-base-directory>
chattr +t <vserver-base-directory>
Warning for 1.26(1.25): The +t attribute is inherited and you won't be able to modify files and directories that have this flag set. Recent version ot util-vserver care about this, but older ones simply do not know about this and you'll have to remove the flag yourself.
1.27[edit]
the unwanted inheritance was fixed in the kernel patch
1.29.1[edit]
the barrier security was lowered to allow for sequences like:
cd /tmp; mkdir foo; mkdir foo/bar chmod 0000 foo; chmod 0000 foo/bar
so make sure that the barrier conditions (i.e. chmod 000 and chattr +t) are met.
1.37+[edit]
similar to 1.9.x ...
1.9.x[edit]
the barrier has become a separate flag, which can be set with recent tools
setattr --barrier <vserver-base-directory>