Posted on | October 26, 2007 | No Comments
Theo de Raadt made some rather general (and sweeping) statements regarding how virtualization might or might not increase or decrease security. I’m not at all concerned with the things that he suggests.
Many programmers have never had to deal with the hosting (IAAS) industry. When you sell access to GNU/Linux (Or BSD) computers to anyone with $5 and a PayPal account or credit card, your administrative world becomes rather interesting. We, (IAAS providers) have literally no control over what users of our network are going to upload and do with the resources that they purchase. Virtualization is our only real hope of damage control.
Minimizing the reach of potential damage at the application level through the use of a well known, tested and proven hypervisor such as Xen DRAMATICALLY increases overall security. Raadt failed to realize, the level of increased security obtained through virtualization is completely relative to how volatile the network in question was prior to adopting the technology.
Raadt argued that since x86 platforms do not provide suitable page protection (and isolation) that every hypervisor is inherently weak. He’s not incorrect about the intrinsic quirks of the x86 architecture, however, show me one exploit? Show me one vulnerability in Xen (besides a quirky python boot loader) that has been exploited causing a breach. The pygrub issue does not represent the type of hole he’s describing. He can’t demonstrate an exploit, there isn’t one. He’s just assuming that there must be one, which makes his outburst a scarecrow argument.
When we look at security in an operating system, we need to break things down to minute degrees in order to address potential issues effectively:
- Kernel level – how well written is the kernel?
- OS level, how well written is the OS? (shells, UI’s, core applications, etc)
- Network level – how inherently secure are the network protocols in use? (i.e. TCP/IP)
- Application level – How secure are things like Apache, PHP, Python, Perl, or other things that anonymous people can interact with that is not a primary part of the OS?
- … several more, I don’t want to put you to sleep.
By isolating your users in their own worlds (a la Xen), a compromised PHP script on one virtual machine has no hopes of effecting the rest. Some of this is due to the isolation that Xen provides when deployed sensibly and correctly.
Lets take a shared web server that hosts 500 people. One successful hack due to a poorly configured Apache/PHP setup means that everyone on that server may suffer data theft or worse. How can isolated containers NOT help in that sort of setting?
Are there yet undiscovered exploits in Xen? Who knows, I can’t document a negative. Will there be an exploit discovered in Xen that can’t be fixed due to the quirks in x86? I sincerely doubt it, so do many other people much smarter than me.