Loop Device
From Linux-VServer
This mini HOWTO explains how to set up loopback devices inside a virtual server. With some work you will be able to mount loop-AES based cryptoloops too. To repeat the steps described here, you're going to fulfill some prerequisites.
Contents |
Prerequisites
- root-access on the host-machine
- The kernel 2.6.16 (or newer) kernel source
- The 2.1.1-rc14 (or newer) vserver-patch
- If you intend to use loop-AES: loop-AES-v3.1c or newer
- some patches, see below
Note: Please keep in mind that you will need, as of the time I write this, some patches to get this working. If you are using newer vserver-patches than 2.1.1-rc14 and/or a newer kernel than 2.6.16 chances are, you don't need some of them.
Security
Keep in mind that doing the changes described later weaken the security of your server. Don't use it on guest hosts you don't trust. If you intend to use loop-AES note that root on the host-machine will still be able to read your crypted filesystem if its mounted.
Setting up the host environment
I expect here, you know how to set up a running linux vserver environment. If not, consult other manuals and HOWTO's. Just patch and configure your vserver kernel as usual. Ensure that you chose to activate loopback devices (CONFIG_BLK_DEV_LOOP). If you plan to use loop-AES deactivate CONFIG_BLK_DEV_LOOP, or build it as module. Therefore you'll need some additional patches to get this feature running inside vserver guests. Depending on your configuration you have to use more or less additional patches. Just answer the following questions:
Do you use kernel 2.6.16 or older
Yes: Apply this patch: http://lkml.org/lkml/2006/3/24/370
Do you use vserver 2.1.1-rc14 or older?
Yes: Apply this patches:
diff -NurpP linux-2.6.16-vs2.1.1-rc14.3/kernel/fork.c linux-2.6.16-vs2.1.1-rc14.4/kernel/fork.c
--- linux-2.6.16-vs2.1.1-rc14.3/kernel/fork.c 2006-03-20 18:09:05 +0100
+++ linux-2.6.16-vs2.1.1-rc14.4/kernel/fork.c 2006-03-25 02:22:55 +0100
@@ -1348,6 +1348,7 @@ long do_fork(unsigned long clone_flags,
if ((clone_flags & CLONE_KTHREAD) && !vx_check(0, VX_ADMIN)) {
vxwprintk(1, "xid=%d tried to spawn a kernel thread.",
vx_current_xid());
+ free_pidmap(pid);
return -EPERM;
}
and
diff -NurpP --minimal linux-2.6.16-vs2.1.1-rc14.1/drivers/block/loop.c linux-2.6.16-vs2.1.1-rc14.2/drivers/block/loop.c
--- linux-2.6.16-vs2.1.1-rc14.1/drivers/block/loop.c 2006-03-20 17:32:31 +0100
+++ linux-2.6.16-vs2.1.1-rc14.2/drivers/block/loop.c 2006-03-24 03:37:07 +0100
@@ -943,7 +943,7 @@ loop_set_status(struct loop_device *lo,
struct loop_func_table *xfer;
if (lo->lo_encrypt_key_size && lo->lo_key_owner != current->uid &&
- !capable(CAP_SYS_ADMIN))
+ !capable(CAP_SYS_ADMIN) && !vx_ccaps(VXC_CRYPTO_LOOP))
return -EPERM;
if (lo->lo_state != Lo_bound)
return -ENXIO;
@@ -1023,7 +1023,8 @@ loop_get_status(struct loop_device *lo,
memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);
info->lo_encrypt_type =
lo->lo_encryption ? lo->lo_encryption->number : 0;
- if (lo->lo_encrypt_key_size && capable(CAP_SYS_ADMIN)) {
+ if (lo->lo_encrypt_key_size &&
+ (capable(CAP_SYS_ADMIN) || vx_ccaps(VXC_CRYPTO_LOOP))) {
info->lo_encrypt_key_size = lo->lo_encrypt_key_size;
memcpy(info->lo_encrypt_key, lo->lo_encrypt_key,
lo->lo_encrypt_key_size);
diff -NurpP --minimal linux-2.6.16-vs2.1.1-rc14.1/include/linux/vserver/context.h linux-2.6.16-vs2.1.1-rc14.2/include/linux/vserver/context.h
--- linux-2.6.16-vs2.1.1-rc14.1/include/linux/vserver/context.h 2006-03-20 18:09:05 +0100
+++ linux-2.6.16-vs2.1.1-rc14.2/include/linux/vserver/context.h 2006-03-24 03:35:26 +0100
@@ -76,6 +76,7 @@
#define VXC_BINARY_MOUNT 0x00040000
#define VXC_QUOTA_CTL 0x00100000
+#define VXC_CRYPTO_LOOP 0x00200000
/* context state changes */
Once this patches are commited to your kernel source, (re)compile and boot it.
change capabilities files
You have to make some changes in the capabilities files too. If they don't exist already, just create them. Usually they can be found under /etc/vservers/<guest name>/bcapabilities and /etc/vservers/<guest name>/ccapabilities.
ccapabilities
^21 secure_mount secure_remount
^21 is VXC_CRYPTO_LOOP, but as of version 0.30.210 the util-vserver don't recognize this flag (yet).
bcapabilities
CAP_IPC_LOCK
Building loop-AES
If you plan to use loop-AES you have to apply an additional patch. Since loop-AES replaces the kernels loopback device you have to tell loop-AES about the changes in your vserver kernel. It's a quite simple patch, apply it to your loop-AES source.
diff -ruN loop-AES-v3.1c-orig/loop.c-2.6.patched loop-AES-v3.1c/loop.c-2.6.patched
--- loop-AES-v3.1c-orig/loop.c-2.6.patched 2006-01-12 19:22:48.000000000 +0100
+++ loop-AES-v3.1c/loop.c-2.6.patched 2006-03-25 03:09:59.000000000 +0100
@@ -102,6 +102,8 @@
#endif
#include <asm/uaccess.h>
+#include <linux/vserver/context.h>
+#include <linux/vs_context.h>
#if !defined(LO_FLAGS_DO_BMAP)
# define LO_FLAGS_DO_BMAP 0x20000
@@ -1267,6 +1269,7 @@
struct file *file;
struct inode *inode;
struct block_device *lo_device = NULL;
+ struct vx_info_save vxis;
int lo_flags = 0;
int error;
@@ -1412,7 +1415,9 @@
loop_set_softblksz(lo, bdev);
+ __enter_vx_admin(&vxis);
error = kernel_thread(loop_thread, lo, CLONE_KERNEL);
+ __leave_vx_admin(&vxis);
if(error < 0)
goto out_mapping;
wait_for_completion(&LDE_lo_done);
@@ -1527,7 +1532,7 @@
struct loop_func_table *xfer = NULL;
if (lo->lo_encrypt_key_size && lo->lo_key_owner != current->uid &&
- !capable(CAP_SYS_ADMIN))
+ !capable(CAP_SYS_ADMIN) && !vx_ccaps(VXC_CRYPTO_LOOP))
return -EPERM;
if ((unsigned int) info->lo_encrypt_key_size > LO_KEY_SIZE)
return -EINVAL;
@@ -1607,7 +1612,8 @@
memcpy(info->lo_file_name, lo->lo_file_name, LO_NAME_SIZE);
memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);
info->lo_encrypt_type = lo->lo_encryption ? lo->lo_encryption->number : 0;
- if (lo->lo_encrypt_key_size && capable(CAP_SYS_ADMIN)) {
+ if (lo->lo_encrypt_key_size &&
+ (capable(CAP_SYS_ADMIN) || vx_ccaps(VXC_CRYPTO_LOOP))) {
info->lo_encrypt_key_size = lo->lo_encrypt_key_size;
memcpy(info->lo_encrypt_key, lo->lo_encrypt_key,
lo->lo_encrypt_key_size);
Once done, just (re)compile loop-AES with make clean && make. You should now be able to load the loop-AES module. Simply type modprobe loop. If you want to do make tests ensure, you have installed the patched aes utils on your host system.
Setting up the guest environment
You have to create some devices on your guest host, namely /dev/loop* and, if you set-up loop-AES even /dev/zero} and {{/dev/null. If /dev/loop0 to /dev/loop7 does not already exist on your host, just create them with
mknod -m 600 /dev/loop0 b 7 0 mknod -m 600 /dev/loop0 b 7 0 mknod -m 600 /dev/loop1 b 7 1 mknod -m 600 /dev/loop2 b 7 2 mknod -m 600 /dev/loop3 b 7 3 mknod -m 600 /dev/loop4 b 7 4 mknod -m 600 /dev/loop5 b 7 5 mknod -m 600 /dev/loop5 b 7 6 mknod -m 600 /dev/loop6 b 7 6 mknod -m 600 /dev/loop7 b 7 7
then copy all the necessary devices to your guest system:
cp -a /dev/null /dev/zero /dev/loop* /path/to/your/vhost/images/dev
You're now done in the host system. Change to your guest image, e.g. with vserver imagename enter.
Using loop-AES you'll now need to install the loop-aes-utils on your guest system. Check your distributions packages for prebuilt images. On Debian use
apt-get install loop-aes-utils
Setting up a simple loopback
Follow the usual steps. Note, that you have to be logged in as root user (the example will create a 5M loopback):
dd if=/dev/zero of=/container bs=1024 count=5120 mkfs.ext2 /container mount -t ext2 -o ro,loop=/dev/loop0 container /mnt/
Setting up a loop-AES loopback
Even loop-AES is not different from a generic set up. Ensure, you are logged in as root
dd if=/dev/zero of=/container bs=1024 count=5120 losetup -e AES128 /dev/loop0 /container mkfs -t ext2 /dev/loop0 losetup -d /dev/loop0 mount -t ext2 -o loop=/dev/loop0,encryption=AES128 /container /mnt/
Using loopback devices on multiple guests
Keep in mind, that you can't use the same loopback device twice or more. Therefore your guests will be unable to mount any content to /dev/loopX if this device is already mounted in any other context, including the host filesystem. If you have multiple guests it might be a good idea assigning them just one device, not all, so guests can block only one. Without any furhter work you can use up to 8 devices, the driver supports up to 255 though.
