Virtualization Decreases Security 340
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."
Counterargument (Score:3, Insightful)
Perhaps a Different Train of Thought (Score:5, Insightful)
You've been smoking something really mind altering, and I think you should share it.
x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.
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.
You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it.
That's all x86 virtualization is.
However, his technical argument is
I'm going to point out some other things I know about coding. Although more lines of code usually means more bugs, this is not always the case. Correlation does not equal causation. It is correlated but only because the more lines of code, the more probability that more people contributed to the project which means it is highly probable one of them was a bad coder. Also, if you plan things out and follow a rigorous model, it is within your power to make very fully functional, very nice software.
My second point is a different way of looking at the problem. Let's take the naive approach of assuming a primary job of the operating system is to protect the user (and applications) from completely fouling things up in the hardware & memory realm. So it does an 'ok' job at this but, as Theo noted, some bugs still exist. Let's say it's something really bad like they don't stop programs from altering a very sensitive range of memory that is very vital to the correct execution of the operating system itself. Now, hypothetically, the virtualized layer on top of this would give coders a chance to catch this and correct it and protect the user from bringing down the operating system. In this way of looking at things you have two nets. Alone one lets many things pass through so you double it up and now you're catching more fish.
But my analogy is probably very flawed and I must confess I have coded neither of these pieces of software so I cannot confirm or deny this. I am quite shocked that Mr. de Raadt would react so abusively to a post where someone was merely saying that they 'appeared' to be receiving some amount of additional security from virtualization.
As for the very last comment Mr. de Raadt makes, I am confused. My employer uses virtualization on a mass scale to more effectively utilize hardware. I believe it has more uses than just bright shiny colors and wrapping--in fact I am interested in its potentials for hosting web OSs and other neat applications to users. It might not be the future like some people think it is but I think Mr. de Raadt was suffering a moment of frustration or dealing with irritable people when he authored this.
I do wish he were open to more ideas. The second you start to just outright dismiss all your options because they don't satisfy you on the surface you will find you are left with none and often miss the best.
Theo is so full of himself he misses reality (Score:2, Insightful)
Risk profiles (Score:5, Insightful)
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.
Re:History teaches once again... (Score:4, Insightful)
Re:Welcome to the rest of the IT world, Theo! (Score:5, Insightful)
Re:History teaches once again... (Score:5, Insightful)
There's still a lesson in diversity and computer security to be learned here. But it includes the harsher lesson that human leaders often don't care about the necessity for diversity and the cost to security (and thus the IT department), and can impose a homogeneity that is even worse than an IT department that just didn't consider diversity to be important.
credibility? (Score:4, Insightful)
He's in the same bucket as Dvorak - who wants to listen to the little twerp?
Re:Uh oh (Score:5, Insightful)
They consider him a brilliant man, and excellent programmer, and generous to let people download his code. They consider him a hero for taking on and beating the US government. They consider him a jerk. I've never heard anybody call him a leader of the Free Software Movement. I've never even heard his license-free software to be considered Free Software.
As an aside, many people call him a jerk for his style of writing information and documentation. I had to install a DNS server, and I found his you-must-be-a-moron-so-I-will-explain-everything-in-very-simple-terms documentation very informative, clear, and helpful. The security advantage is nice, but to me, tinydns' greatest advantage was the DJB's documentation.
Re:History teaches once again... (Score:3, Insightful)
Re:History teaches once again... (Score:3, Insightful)
Keep in mind that the base debate is whether a virtualized environment is "more secure" or not. I understand where the initial idea is coming from; the ability to provide various groups with their own virtual host to configure / jeopardize. But I must admit I haven't seen anything that convinces me one box with two virtualized hosts is any more secure than two seperate hosts on two seperate boxes. The only advantages to be found is in dealing with cost and/or utility of hardware.
Re:Perhaps a Different Train of Thought (Score:3, Insightful)
1. He uses troll-like sentences that divert away from the technical discussion. E.g. he says "You are absolutely deluded, if not stupid, if you think that..." rather than just saying "It is incorrect to say that..." In each post, he throws in some needlessly inflammatory sentences and personal attacks.
2. He uses idioms and analogies that do more to confuse than to get a point across. E.g. he says "The security benefits are at the 'ability to buy a steak for dinner' level." It's not at all clear what useful information is added to the discussion with sentences like that.
3. He is dismissive in his responses to the point of being uninformative. If he had simply laid out his entire argument in the first email, then others could judge the quality of his logic. Instead he dismisses the entire discussion with things like: "You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it. That's all x86 virtualization is." This is supposed to be a technical discussion but instead he leaves all the details to the imagination.
4. He makes bold assertions without citations. He simply relies on his 'authority' (e.g. "Those of us who have experience with the gory bits of the x86 architecture...") rather than pointing out specifics. (For example, in this Slashdot thread, many people have posted links to actual examples of exploits where code was injected into the host OS. Why could he not have provided similar real-world data to back up his point?)
While we can all agree that the message/argument is more important than who delivers it, the means by which they deliver it absolutely has an effect on how quickly people will understand the logic. By being so inflammatory and dismissive, Theo turns an opportunity to educate others on security (and x86 hardware design) into a protracted back-and-forth where he mentions a few isolated facts per post. At the end of the day, he is right, and his argument is sound... but his style of discourse is very inefficient for convincing others of a technical point.
This doesn't just go for Theo. Many geeks have a superiority complex that causes them to be acerbic, arrogant, and dismissive in technical discussions. This is just a reminder that doing so merely causes the discussion to take longer than it would have otherwise.
Theo's pessimism and where it comes from. (Score:5, Insightful)
This doesn't mean that OpenBSD won't get some kind of virtualization support, it just means that he's being careful and conservative and letting other people be the pioneers. I think this is a good thing, on balance... you don't want to be pulling arrows out of your back because your secure OS decided to take you through unknown territory.
Yeh, he's got an emphatic way of putting things. You just gotta deal with it. Several years ago I asked him about stack protection and his response was eerily similar to this. A few years later OpenBSD enabled stack protection by default.
I think he's got a point, but he's comparing running separate computers to running separate OS instances on the same computer. If that's how you're using VMs, then yes, the resulting system is less secure overall... and for Windows that's often how VMs get used because Windows tends to make it unreasonably hard to run multiple instances of the same application on the same computer. If you're replacing less extreme isolation mechanisms on the same computer with VMs, though, then you're adding an extra layer of defence. Think of it as a hierarchy...
* Same application instance (eg, web server modules)
* Separate applications (running multiple instances of apache)
* User level separation (multiple accounts for the separate instances)
* File system separation (multiple chrooted instances of apache)
* OS-level separation (eg, FreeBSD jails and I think Solaris domains)
* Hardware-assisted software virtualization (VMware, Xen)
* Hardware virtualization (IBM VM "penguin farms")
* Separate physical computers
It might be argued that IBM's virtual machines should be lumped with virtualization, or that separate computers should be split from blades, and things like NAS and SAN complicate things, but you get the idea.
Theo's looking at the hierarchy starting at the bottom, and seeing a reduction in security. Other people are starting at the top, and seeing an increase in security. Both sides are correct, it depends on where you start.
Re:Uh oh (Score:5, Insightful)
After reading vitriolic posts by these two fools, RMS doesn't seem all that bad.
I've been on the fence about virtualization for a very long time now. Sure, it's quite convenient to install VMware, load up a guest OS, and tinker with new features. But to load up a server with multiple instances of the same operating system is ludicrous. It certainly doesn't scale well at all. And the marketing teams are incredibly good at making people believe that by installing their virtualization software, you'll suddenly have a bunch of "virtual" servers with the same capabilities as a single server. Sure, they all have the same capabilities from an OS standpoint, but performance isn't going to be anything close to a standalone server..
And as far as security goes, it's nonsense. Ok, so I install 5 copies of RHEL 5.0 on my virtual server. If the virtualization software itself is attacked and compromised, all 5 servers go down. If an OS level attack is successful, then all 5 virtual servers are likely vulnerable because it's an OS level attack. The only security "benefit" I can see is if a single virtual server is compromised through something like a web application. That application may not exist on the other virtual servers, so they're "safe".. However, once you get into that one server, DDoS attacks aren't far behind. At the very least, you'll take up resources and you can potentially impact the operation of the other virtual servers.
I'll stick with standalone servers for now.. At least until there's a better solution, of which I don't see one coming anytime soon...
Re:When a Port is Lagging Behind the Mainstream (Score:4, Insightful)
Because I have a wealth of already working solutions to choose from. Why in the fuck would I waste my time contributing to a project full of assholes (read the mailing lists for details) who don't even want to admit there's a problem in the first place -much less fix it?
Don't know about you, but I've got a life to live; if OpenBSD doesn't feel like offering virtualisation technology (or -in the case of WINE- compatibility functionality) then I'll simply move on and use operating systems which do.
And if Theo insists on making it sound as if the problem isn't OpenBSD's inability to support virtualisation but virtualisation itself; then I reserve the right to laugh my ass off at his extremely silly pompousness.
Re:History teaches once again... (Score:5, Insightful)
Actually Theo's argument was that software engineers can't write an OS without security holes, therefore they can't write a hypervisor without security holes.
The argument is, of course, full of shit. The hypervisor in question, Xen, is 50,000 lines of code. Compare this to the linux kernel which is about 6 million lines of code or Vista which is said to be 10s of millions. Theo also drags out his favorite attack about page protection. He is known for attacking a "vulnerability" in a C2D code segment limit/page accessed issue (AI90) as being "assuredly exploitable" in OSes other than OpenBSD, even though nobody has been able to propose a way to exploit it.
The problem with Theo attacking things is that he is so well respected in BSD-land that his word is taken for granted. Sometimes he gets it wrong, but unless someone equally high up wants to spend the time to rebut his ranting (a lot of work for no gain) everybody accepts what he says.
Re:Uh oh (Score:2, Insightful)
It is sad that he doesn't acknowledge that the larger your trusted code base the less secure you are.
Re:History teaches once again... (Score:3, Insightful)
Re:History teaches once again... (Score:3, Insightful)
And you know what, I don't freaking care about that. If I can trade a little theoretical attack surface for real world gains I'd be foolish to not consider it. I mean we do it every day when we use normal OS's instead of something like Trusted Solaris, so why not do it to see significant gains. The gains are reduced server count, reduced electricity use, reduced physical plant, etc. Those have significant direct and indirect benefits (lowered cost and less environmental impact primarily). I guess if you're a security zealot you wouldn't even consider the tradeoff, but for those of us in the real world it's probably not a tough sell.
He's right, in theory (Score:5, Insightful)
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]
Re:credibility? (Score:2, Insightful)
I don't know if Theo gets this, or simply doesn't care— my bet's on the latter.
Re:History teaches once again... (Score:3, Insightful)
I think his point was to make people aware of the tradeoff. He's telling them that those reasons are perfectly valid, but you should know what new risks you're exposing your systems to so you can make that decision with full knowledge. I do know people who equate VMWare with security, and that's just not true. He wants everyone to understand that.
Re:Uh oh (Score:5, Insightful)
Performance will take a hit from the overhead involved, but availability should increase. Most server applications don't fully utilize the CPU anyway, so sacrificing some cycles to run the apps in a virtualized environment is not really a big deal. Where virtualization shines is availability. If a server is malfunctioning or overburdened, the virtualized environment can migrate to another server without the server clients knowing this has taken place (other than some latency caused by the migration). This is actually the coolest part of this technology.
I never thought about using virtual servers to increase security. Except for running windows within Mac OS X, I really don't see virtualization making anything more secure.
I think this is much ado about nothing. It is only here because Theo is getting upset...
It's easy to defeat Theo's argument (Score:5, Insightful)
There doesn't need to be a flame war, because in this particular instance Theo's argument has a gaping hole in it. Consider the following two system architectures:
1) An ordinary multi-function Unix-type system which also runs a non-trivial component that is exposed to the world (all non-trivial components have bugs, as Theo is right to point out, and hence are attack vectors).
2) A machine running 2-guest virtualization, in which the non-trivial component runs in one guest, and the rest of the functions run in another.
Now consider what happens when the world-facing component gets compromised, and by one of many methods (because sysadmins are fallible) the attack gets promoted to root privilege. Security has failed in one guest, but has it failed in the other? Not necessarily, depending on whether the sysadmin has made repeated blunders and not just one. (Eg. a fool might be keeping ssh keys on the public-facing guest
In this scenario, the isolation created by virtualization has given the syadmin an additional bulkhead against his own fallibility, and that is worthwhile for security, not only for better hardware utilization. The partitioning of the application and O/S space has reduced the cross-section of software open to attack.
Theo's argument also doesn't bear scrutiny at the hypervisor level, because while an O/S in dom0 is just as fragile as the one in domU that runs an exposed application, the instance in the hypervisor isn't exposed to attack. Theo seems to miss the distinction between endpoint fallibility and fallibility in the conveyance and resourcing that is done by hypervisors. They're different.
I like Theo's hard stance on security, but on this issue he's handwaving.
Re:It's easy to defeat Theo's argument (Score:5, Insightful)
Chris Mattern
Re:Sounds to me like "those who can't, bitch" (Score:2, Insightful)
Re:It's easy to defeat Theo's argument (Score:1, Insightful)
Re:Except that the VM isn't exposed (Score:3, Insightful)
And thats one of the reason why, as much as I totally *hate* to admit it, Theo is right about this.
On of the other reasons is the simple fact that running more code on your system means more potential bugs, allways. Or perhaps the stupid trivial fact that it doesn't really matter if the machine that is pwned is virtual or not, its not like those creditcard records suddenly become virtual when you start using Xen.
I *might* *maybe* *sometimes* help security a bit when you are using it to separate software which was allready running on the same machine, but I have yet to find the first real live scenario for that. After all, if it's allready running perfectly on the same machine, what would you gain from virtualization?