Virtually Reluctant

Tuesday 12 June 2007 by Bradley M. Kuhn

Way back when User Mode Linux (UML) was the “only way” the Free Software world did anything like virtualization, I was already skeptical. Those of us who lived through the coming of age of Internet security — with a remote root exploit for every day of the week — became obsessed with the chroot and its ultimate limitations. Each possible upgrade to a better, more robust virtual environment was met with suspicion on the security front. I joined the many who doubted that you could truly secure a machine that offered disjoint services provisioned on the same physical machine. I've recently revisited this position. I won't say that Xen has completely changed my mind, but I am open-minded enough again to experiment.

For more than a decade, I have used chroots as a mechanism to segment a service that needed to run on a given box. In the old days of ancient BINDs and sendmails, this was often the best we could do when living with a program we didn't fully trust to be clean of remotely exploitable bugs.

I suppose those days gave us all rather strange sense of computer security. I constantly have the sense that two services running on the same box always endanger each other in some fundamental way. It therefore took me a while before I was comfortable with the resurgence of virtualization.

However, what ultimately drew me in was the simple fact that modern hardware is just too darn fast. It's tough to get a machine these days that isn't ridiculously overpowered for most tasks you put in front of it. CPUs sit idle; RAM sits empty. We should make more efficient use of the hardware we have.

Even with that reality, I might have given up if it wasn't so easy. I found a good link about Debian on Xen, a useful entry in the Xen Wiki, and some good network and LVM examples. I also quickly learned how to use RAID/LVM together for disk redundancy inside Xen instances. I even got bonded ethernet working with some help to add additional network redundancy.

So, one Saturday morning, I headed into the office, and left that afternoon with two virtual servers running. It helped that Xen 3.0 is packaged properly for recent Ubuntu versions, and a few obvious apt-get installs get you what you need on edgy and feisty. In fact, I only struggled (and only just a bit) with the network, but quickly discovered two important facts:

  • VIF network routing in my opinion is a bit easier to configure and more stable than VIF bridging, even if routing is a bit slower.
  • sysctl -w net.ipv4.conf.DEVICE.proxy_arp=1 is needed to make the network routing down into the instances work properly.

I'm not completely comfortable yet with the security of virtualization. Of course, locking down the Dom0 is absolutely essential, because there lies the keys to your virtual kingdom. I lock it down with iptables so that only SSH from a few trusted hosts comes in, and even services as fundamental as DNS can only be had from a few trusted places. But, I still find myself imagining ways people can bust through the instance kernels and find their way to the hypervisor.

I'd really love to see a strong line-by-line code audit of the hypervisor and related utilities to be sure we've got something we can trust. However, in the meantime, I certainly have been sold on the value of this approach, and am glad it's so easy to set up.

Posted on Tuesday 12 June 2007 at 14:10 by Bradley M. Kuhn.

Submit comments on this post to <bkuhn@ebb.org>.



Creative Commons License This website and all documents on it are licensed under a Creative Commons Attribution-Share Alike 3.0 United States License .


#include <std/disclaimer.h>
use Standard::Disclaimer;
from standard import disclaimer
SELECT full_text FROM standard WHERE type = 'disclaimer';

Both previously and presently, I have been employed by and/or done work for various organizations that also have views on Free, Libre, and Open Source Software. As should be blatantly obvious, this is my website, not theirs, so please do not assume views and opinions here belong to any such organization.

— bkuhn


ebb is a (currently) unregistered service mark of Bradley M. Kuhn.

Bradley M. Kuhn <bkuhn@ebb.org>