Slashdot Mirror
Virtualization Decreases Security
ParaFan writes "In a fascinating story on KernelTrap, Theo de Raadt asserts that while virtualization can increase hardware utilization, it does not in any way improve security. In fact, he contends the exact opposite is true: 'You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.' de Raadt argues that the lack of support for process isolation on x86 hardware combined with numerous bugs in the architecture are a formula for virtualization decreasing overall security, not increasing it."
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Virtualization is no doubt a complex problem to get right, but it's only one problem. There is a relatively fixed set of hardware any virtualization system claims to support. A reasonably complete virtualization system can be frozen at some level of functionality. An operating system can not; it must, by nature, constantly evolve to new requirements. Hardware, in contrast, is relatively more stable.
Operating systems running on virtualized systems also have the advantages of operating systems running any fixed configuration. While not quite as consistent as a completely emulated environment, virtualization gets most of the benefits, under reasonable assumptions.
So, in short, virtualization has the same sort of benefits microkernels were supposed to provide, albeit with a much more heavyweight solution: smaller core that's easier to secure. Virtualization has been used in the mainframe community for years. Virtualization is an even stronger form of process isolation than what operating systems provide.
Virtualization is much more costly to run than a standard operating system process. This should be a clue that it probably provides stronger isolation guarantees, even if you don't buy the rest of the argument.
I think it's a specious argument, as usual, to claim that securing the virtualization layer is no harder or easier than securing an operating system. I think securing the virtualization layer is going to be much easier, because while the problem itself is complex, it's still less complex than a complete operating system is.
A better argument would have been to point out that guest operating systems running under virtualization are no less vulnerable to being compromised than those running on real hardware. But then that would point the finger at operating system vendors, not virtualization ones.
However, I see this more as if the virtualization layer actually sits under the OS layer, then the actual security for remote intrusion would be, first, Y/OS(X), THEN Y/V(X), where Y is the number of people with the knowledge to exploit each vulnerability. Thus, someone who wanted to exploit the system would both have to be capable of exploiting an OS vulnerability, and THEN also exploiting a virtualization vulnerability.
(And we're talking about remote usage, because we all know it's virtually impossible to protect a system from anyone who has direct access to the hardware.)
I understand that reality may not be quite as tidy, but it still seems like a virtualized system would be much more secure that a non-virtualized system, if only because the increased level of knowledge involved means a smaller number of hackers capable of exploiting both layers. What am I missing?
Lawrence Person (lawrencepersonh@gmailh.com (remove all "h"s to mail)
http://www.lawrenceperson.com/
Not to put it as harshly as the AC, but you don't know what you're talking about. Are you a sysadmin of any kind? Security was never the direct reason for virtualization. Utilization was. Now, virtualization may not help with crackers, but it does help isolate configuration issues, runaway processes and things like that. Admins like to keep one app on one machine because in a production environment, we are afraid of borking things that are currently working. Virtualization lets us keep one app per virtual machine, while letting us more fully utilize our physical hardware. This cuts down on electrical and cooling bills, & frees up rackspace. Mainframes have been doing this for decades.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
You're missing the point. Your virtualization product is an application, which weakens the security of the OS running under it. So now you can have attacks from both sides. As Theo says, now an OS crash (inside the VM) can become an attack on the host system, and application attacks on the VM can become an attack on the OS running in the VM.
His position has many facets. As I understand it:
* programmers make buggy code, and now programmers are programming virtual hardware
* the hardware they are emulating (PC architecture) is a nightmare, they have to do crazy, unsafe crap to implement it.
* application flaws in the VM can compromise the guest OS.
* OS flaws in the guest OS can potentially compromise the host OS.
* virtualizing hardware is inherently less secure than the physical segmentation of using actual, separate machines, so when you consolidate many machines onto a VM system you have a net loss in security.
[disclosure text="I work for a company that sells virtualization."]
Theo's expertise, and indeed that of the entire OpenBSD project, is in the realm of provably correct security. Virtualization adds yet another layer where something can go wrong. Sure there are and will be bugs. We're finding them and fixing them, just as we've always done. From an absolute security standpoint, Theo's right.
Of course, most businesses couldn't care less. Businesses don't view security as an absolute thing, because human factors make it generally impossible. Businesses view security as a risk, with associated probabilities and costs, worst-case scenarios, likely scenarios, mitigation strategies, and ultimately, diminishing marginal returns. For businesses using virtualization to consolidate systems, it generally reduces risk because it makes it easier to implement policies that mitigate human factors.
To be precise, virtualization *technology* decreases security, but virtualization *solutions* increase security, at least when done well, which is much more practical than the technical absolute of "done right".
[/disclosure]
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
I don't think you've entirely grasped Theo's argument. He argues that your reasoning is invalid *because it assumes that the interface between the O/S in dom0 and the hypervisor has no security holes in it*. You don't get to just state that the hypervisor isn't exposed to attack. Now, you can argue that because of its limited nature, and because great pains are taken to avoid unwanted interaction between the hypervisor and the virutal O/S, it is more secure than ordinary software interactions. But I think Theo is not arguing that VMs are less secure than running all your stuff in one O/S. I think he's arguing that VNs are less secure than running your services *on actual separate machines*. And that stands a good chance of being true.
Chris Mattern