Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Virtualization Decreases Security

kdawson posted more than 6 years ago | from the more-chances-to-blow-it dept.

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."

cancel ×

340 comments

Sorry! There are no comments related to the filter you selected.

Uh oh (5, Funny)

$RANDOMLUSER (804576) | more than 6 years ago | (#21114697)

Theo de Raadt asserts...
CAUTION: flame war ahead.

Re:Uh oh (4, Funny)

Anonymous Coward | more than 6 years ago | (#21114805)

CAUTION: flame war ahead.
No there isn't! How dare you say that?? F-you! YOU GO TO HELL AND YOU DIE!!!

Re:Uh oh (0, Flamebait)

Chas (5144) | more than 6 years ago | (#21115073)

Yep. As with everything else Theo does, it's starts out with "ass".

Re:Uh oh (1, Interesting)

Anonymous Coward | more than 6 years ago | (#21115101)

We should put Theo and Daniel J. Bernstein (DJB) [cr.yp.to] and see who survives. These so-called 'visionaries' and have a hard time forming an argument without degrading the argument with words like 'stupid'. It's a real shame that men like these are considered leaders the Free Software movement.

After reading vitriolic posts by these two fools, RMS doesn't seem all that bad.

Re:Uh oh (0)

Anonymous Coward | more than 6 years ago | (#21115219)

These so-called 'visionaries' and have a hard time forming an argument without degrading the argument with words like 'stupid'. It's a real shame that men like these are considered leaders the Free Software movement.


At least they can form coherent sentences.

Re:Uh oh (4, Insightful)

oyenstikker (536040) | more than 6 years ago | (#21115307)

I don't think anybody considers DJB a leader of the Free Software movement.

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:Uh oh (4, Insightful)

XenoPhage (242134) | more than 6 years ago | (#21115721)

We should put Theo and Daniel J. Bernstein (DJB) [cr.yp.to] and see who survives. These so-called 'visionaries' and have a hard time forming an argument without degrading the argument with words like 'stupid'. It's a real shame that men like these are considered leaders the Free Software movement.

After reading vitriolic posts by these two fools, RMS doesn't seem all that bad.
I disagree. He seems to call it like it is. And I would agree that anyone deluded enough to think that adding another layer to the, already complex, PC model increases security is just stupid. Sure, it may be that they are not well versed in the inner workings of both the hardware and software, but does that make their assertion any more correct? And besides, he's on a mailing list where the majority of the readers should be close to his level of knowledge.. He may not be the most tactful guy in the world, but he's a hell of a lot smarter than most...

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...

If they mated ... (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21115329)

de Raadt + Rutkowska =

Re:Uh oh (1)

xorbe (249648) | more than 6 years ago | (#21115657)

This guy should not operate in a PR capacity at all!

History teaches once again... (1, Interesting)

jellomizer (103300) | more than 6 years ago | (#21114719)

The Irish Potato Famine happened because Ireland was growing a small range of species of potato.
A virus hit the Potato and it spread so most of the potato's died thus causing the famine.
Other Areas had the same virus but it didn't cause a Famine because their stock was more diverse.
It wasn't because the other guys potatoes were immune to all virus or they were a heartier bread, but
because they had a wider diversity of product.

The same thing with Virtualization, each VM will not be completely secure and will have holes in it but
spreading will be reduced because only a smaller portion of application will use that OS to virtualize.
A Linux VM OS, a BSD VM OS, a Windows VM OS... Sure there will be security problems and patching and fixing
the problems in the Virtual OS will need to be resolved... But if there is an outbrake you will basicly loose your
VM application and perhaps some other ones that you may have running at the same time that uses the same OS. But now
If your OS Gets infected all your Apps are dead.

Re:History teaches once again... (2, Informative)

micromuncher (171881) | more than 6 years ago | (#21114749)

You missed the part about the solution; eating ones children. :-)

Re:History teaches once again... (1)

jellomizer (103300) | more than 6 years ago | (#21114811)

It is not sustainable. It takes more calories to produce a child then you get from eating them. It may only fix the problem in the short term, but in the long term you are better off putting them to work plaining new crops.

Re:History teaches once again... (3, Funny)

mdielmann (514750) | more than 6 years ago | (#21115121)

It is not sustainable. It takes more calories to produce a child then you get from eating them.
This assumes that you eat (only) your own children.

You mean baby MULCHING (1)

shking (125052) | more than 6 years ago | (#21115145)

"software which OpenBSD uses and redistributes must be free to all (be they people or companies), for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines [neohapsis.com] or atomic bombs to be dropped on Australia" — Theo de Raadt

Re:History teaches once again... (3, Informative)

Bob-taro (996889) | more than 6 years ago | (#21114903)

The Irish Potato Famine happened because Ireland was growing a small range of species of potato.

The same thing with Virtualization, each VM will not be completely secure and will have holes in it but spreading will be reduced because only a smaller portion of application will use that OS to virtualize.

I don't think that analogy applies here. I think TA's point is that the hypervisor itself may not be any more secure than the OSes it virtualizes. So now you're hypervisor OR the OS it's running may get hacked.

Re:History teaches once again... (3, Insightful)

jellomizer (103300) | more than 6 years ago | (#21114959)

Well right now most flaws are threw Applications anyways. I can run Open BSD and still make an application that runs as root and have such a major security flaw that it will allow people to have full access to my system. At least with it being virtualized it will at least protect it from quickly spreading to my other Apps.

Re:History teaches once again... (5, Informative)

alan_dershowitz (586542) | more than 6 years ago | (#21115319)

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.

Re:History teaches once again... (1)

davidwr (791652) | more than 6 years ago | (#21115739)

* programmers make buggy code, and now programmers are programming virtual hardware
Real hardware is not without bugs. I'll concede real hardware likely has fewer bugs because the cost of patching is so much higher.

* the hardware they are emulating (PC architecture) is a nightmare, they have to do crazy, unsafe crap to implement it.
Ok fine.

* application flaws in the VM can compromise the guest OS.
OK fine. The same goes for bugs in real hardware.

* OS flaws in the guest OS can potentially compromise the host OS.
If the guest OS and the underlying real hardware are well-designed and bug-free this won't happen. It's much better to say OS flaws in the guest OS combined with design or implementation flaws in the VM, host OS, and/or real hardware 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.
It might be somewhat less secure but it provides enormous benefits.

Ideally, a good engineer will consider all the pluses and minuses of a particular VM before deciding to change from pure hardware to a VM environment. In many cases, it will be obvious what to do.

In the real world, a frazzled engineer on his 100th cup of coffee of the day will make an off-the-cuff decision. In the obvious cases he'll get it right. In the not-so-obvious cases hopefully he'll be right more often than wrong.

Re:History teaches once again... (2, Insightful)

alan_dershowitz (586542) | more than 6 years ago | (#21115367)

ack, I didn't address your specific example. Theo's position here is: now, instead of an exploitable app and an exploitable OS, you have two exploitable OS (guest and host) and two exploitable apps (your app and the VM.) Making this worse is that the the exploitability of each individual piece is amplified by the potential promoting of an OS crash into an application exploit (VM.)

Re:History teaches once again... (1)

jcr (53032) | more than 6 years ago | (#21114979)

I think TA's point is that the hypervisor itself may not be any more secure than the OSes it virtualizes.

I would say he's mistaken on that, simply because the hypervisor offers a far smaller surface area for attack.

-jcr

Re:History teaches once again... (1)

darthflo (1095225) | more than 6 years ago | (#21115587)

It doesn't really matter how big the hypervisor's attack surface to the outside world is, as long as a guest running on top of it is in any way able to compromise it. If this is the case (and I don't really doubt it), a hole in one of your guests and the hypervisor will allow an attacker not only to compromise all identical guests but all guests to which said hypervisor has access to. This has the potential to trade whatever efficiency gains virtualization provides for complete lack of control over the whole network from two small vulnerabilities.

Re:History teaches once again... (2, Insightful)

_Sprocket_ (42527) | more than 6 years ago | (#21115405)

I don't think that analogy applies here. I think TA's point is that the hypervisor itself may not be any more secure than the OSes it virtualizes. So now you're hypervisor OR the OS it's running may get hacked
Actually... the gist of argument seems to go deeper. The point being stressed is that the underlying hardware can't provide sufficient separation so its unwise to expect either the host kernel / hypervisor or guest OS to do it. Buggy OS implementations seems to be more historical proof than the issue in itself.

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:History teaches once again... (1)

jours (663228) | more than 6 years ago | (#21115619)

> So now you're hypervisor OR the OS it's running may get hacked

The avenues of attack against a hypervisor number far less than those against a guest OS...and should be zero behind a proper perimeter.

One thing no one mentioned in the article is that virtualization provides a great opportunity for intrusion detection. I haven't seen it implemented by anyone yet (admittedly I haven't been looking) but the concept at least allows for software running at the hypervisor level that could detect misbehaving or compromised guests. Surely something like that would be an increase in security since it would be running outside of the guest OS and not vulnerable to attack itself.

Re:History teaches once again... (1)

the_B0fh (208483) | more than 6 years ago | (#21115737)

And the problem is that once your hypervisor gets owned, all your OTHER OSes are screwed as well, even those that are not potatoes.

Re:History teaches once again... (4, Insightful)

Chris Burke (6130) | more than 6 years ago | (#21115143)

The Irish Potato Famine happened because potato crops were the only thing they could grow on tiny plots of land in sufficient quantity to both pay their English Lords and feed themselves (the latter being the optional part), so when the potato crop failed they didn't have any other food. Other areas had a more diverse potato crop, but more importantly they had other crops entirely and thus even had all their potatoes died, it wouldn't have caused a famine (or at least not anywhere near the scale of the Great Famine) because they had other food to eat. The Irish had no other food source by design of the English, thus causing mass starvation.

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.

Re:History teaches once again... (1)

darthflo (1095225) | more than 6 years ago | (#21115677)

Actually I think virtualization is somewhat able to undermine all advantages diversification has if (and only if) an attacker is able to not only gain access to one guest but also, through that guest, to the hypervisor itself. After that is done, no amount of diversity in your choice of guests will be of any help whatsoever.
Using different hypervisors is a possibility, but there doesn't seem to be real possibility to both provide security and maximum usage of capacity.

Re:History teaches once again... (0)

Anonymous Coward | more than 6 years ago | (#21115355)

a small range of species of potato.

I think it was a single species of potato, with a small range of genotypes. They mostly came from a small number of potatoes brought over from America, thus a small number of genotypes.

Small distinction.

Re:History teaches once again... (1)

somersault (912633) | more than 6 years ago | (#21115435)

Security by obscurity, baby!

Re:History teaches once again... (2, Informative)

DrSkwid (118965) | more than 6 years ago | (#21115561)

> The Irish Potato Famine happened because Ireland ...

You missed the part where the World's richest nation continued to export other foodstuffs from Ireland, refusing to help.

Much as I love the analogy... (1, Informative)

Anonymous Coward | more than 6 years ago | (#21115699)

the cause of the Famine needs to be shared by the idiotic British
government at the time, and the greedy bastard landowners, as
well as the fungus. If the Irish had been free to BUY FOOD FROM
ABROAD not that many people would have starved.

Welcome to the rest of the IT world, Theo! (1)

JazzyJ (1995) | more than 6 years ago | (#21114725)

You're just NOW realizing this???

Re:Welcome to the rest of the IT world, Theo! (2, Interesting)

superpulpsicle (533373) | more than 6 years ago | (#21114849)

Virtualization is overrated. For people who are really in the field to manage, it creates as much overhead as the it solves. Whatever happen to the days when 1 machine is 1 machine. For the people who claim there is benefit, I am starting to be convinced it only benefits where configs are simple.

Re:Welcome to the rest of the IT world, Theo! (0)

Anonymous Coward | more than 6 years ago | (#21114917)

For the people who claim there is benefit, I am starting to be convinced it only benefits where configs are simple.


I'm convinced that you're shitty admin incapable of learning how to manage new technology.

Re:Welcome to the rest of the IT world, Theo! (5, Insightful)

spun (1352) | more than 6 years ago | (#21115071)

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.

Re:Welcome to the rest of the IT world, Theo! (1)

i.r.id10t (595143) | more than 6 years ago | (#21115251)

Not to mention making the hardware generic - you can move the virtual disks from one machine to another (or have it boot them from a SAN, etc) and not worry about the HAL that windows sees changing, even if the "real" HAL does. Makes migrating your "server" to a new box very easy, same with developing and setting up a "box"....

Re:Welcome to the rest of the IT world, Theo! (0)

Anonymous Coward | more than 6 years ago | (#21115695)

Windows Admins like to keep one app on one machine because in a production environment, we are afraid of borking things that are currently working.


You forgot a word; added.

There's no reason why multiple services can't run on one box. You run each as a separate user / UID and set resource limits.

While one app per box is certainly done in the Unix world, IMHO the mindset and prevalense is more likely in the Windows world (especially in the more flakier days of NT 3.x and 4.x, and the practice simply was brought forward to newer revisions).

Re:Welcome to the rest of the IT world, Theo! (0)

Anonymous Coward | more than 6 years ago | (#21115543)

Maybe its overrated, but it certainly has its place.

So many specialized applications believe they "own" a box - all the ports an services. As hardware gets faster and cheaper, its not reasonable to keep a separate box for each application. Recoding those applications, or even just making sure ones that are supposed to cooperate really do, is a nightmare that would take many man-years (and several calendar years) in our organization.

Just think about this:
- getting the applications to cooperate on a single OS, fixing any port conflicts, config conflicts, logging conflicts, scheduling conflicts
- getting all the applications to work on the same version of the same OS.

In my business, we deliver a network as our product with several specialized boxes. To rewrite all that software would be a nightmare. To force our smaller customers to continue to buy, rent space for, and maintain 10+ boxes - running some combination of linux, windows, and solaris, is business suicide. But we can combine boxes into one box with virtualization.

Does it make it harder to maintain? In the short run we have to learn something new. In the long run having a single piece of hardware is an absolute win.

Counterargument (3, Insightful)

Anonymous Coward | more than 6 years ago | (#21114763)

Virtualization layers can be much smaller than operating systems. Hypervisors don't have to do as much as a monolithic kernel does, so they're less prone to security holes.

Re:Counterargument (1)

Kristoph (242780) | more than 6 years ago | (#21115053)

I am not sure how this makes sense given that each VM is actually running a monolithic kernel.

]{

Re:Counterargument (1)

spun (1352) | more than 6 years ago | (#21115109)

You don't get the concept. It doesn't matter what the VMs are doing. The monolithic kernels can get hacked up down and sideways, and if there are no bugs in the hypervisor, the rest of the machine is still secure.

Re:Counterargument (1)

HardcorePooka (1063342) | more than 6 years ago | (#21115225)

I don't think that you could show me any program with 100% perfect code. Yes, OSes get hacked/broken/etc. constantly... so why do you think a hypervisor would be any different? I would have to say I fully agree with Theo on this one. The ability to write perfect code with no exploitable security flaws and no bugs is pretty much beyond what companies are willing to go through in this day and age. The time and money needed to fully test every aspect of every single line of code in a system would delay a product's release so long that the company in question would probably go bankrupt before they ever got to sell it to anyone. Thats why there are updates and patches and new versions that have the exact same functionality as the old...

Re:Counterargument (1)

644bd346996 (1012333) | more than 6 years ago | (#21115311)

Fewer lines of code in the hypervisor makes it easier to audit the whole thing for bugs. Yes, there will still be bugs, but it is quite feasible for a hypervisor to have significantly fewer bugs per line of code than the operating systems it runs.

Perhaps a Different Train of Thought (4, Insightful)

eldavojohn (898314) | more than 6 years ago | (#21114765)

Well, here's his original post : [kerneltrap.org]

Virtualization seems to have a lot of security benefits.

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.
It's highly probable that Theo is right. After reading the above post, it's highly probable he is a very abrasive and one sided individual. But this is a tech forum so I won't get into judging character.

However, his technical argument is ... somewhat unsound in my humble opinion. He seems to follow the train of thought that 1) people are, by nature, erroneous coders 2) virtualization means more code therefore 3) virtualization has more errors.

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.

Re:Perhaps a Different Train of Thought (0)

Anonymous Coward | more than 6 years ago | (#21115317)

I am quite shocked that Mr. de Raadt would react so abusively
With all respect, which rock have you been living under for the last 15 years?

Theo is the same guy who called linux developers "inhuman" because they *very* politely notified a public mailing list that there was a license violation of code in OpenBSD's public CVS server.

I do wish he were open to more ideas.
As long as you're wishing you might as well ask for a pony. (In fact, the odds of you getting a pony are significantly higher than Theo opening his mind a smidge.)

Re:Perhaps a Different Train of Thought (2, Insightful)

kebes (861706) | more than 6 years ago | (#21115411)

It's highly probable that Theo is right. After reading the above post, it's highly probable he is a very abrasive and one sided individual. But this is a tech forum so I won't get into judging character.
This is off-topic but I'm going to say it anyway. After reading the email exchange I find Theo's style quite bothersome. He's a highly skilled hacker and I don't doubt his technical abilities. However his writing style is terrible for technical discussions:

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.

Re:Perhaps a Different Train of Thought (4, Informative)

Colin Smith (2679) | more than 6 years ago | (#21115591)

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.
Actually caused by strong feelings of insecurity. The secure don't need to attack to try to constantly prove their superiority.

 

The only secure OS (1)

Colin Smith (2679) | more than 6 years ago | (#21115437)

One unplugged from the network, with no applications.

If you want to do anything in this world, there is risk and generally, the greater the risk the greater any reward. So while he may well be correct, he's totally missed the point of well, everything. Leave him to stew in his paranoid fantasy world. I'm sure the NSA, CIA or whoever will be happy to use his skills.

 

Re:Perhaps a Different Train of Thought (1)

rk (6314) | more than 6 years ago | (#21115443)

That Theo... he's such a smooth talker. I'll bet he's quite a hit with the ladies.

Re:Perhaps a Different Train of Thought (1)

yuna49 (905461) | more than 6 years ago | (#21115535)

Regardless of Theo's language or his comments about the quality of OS engineers, I thought this argument was more compelling:

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.

Just how nasty is the x86 architecture as a platform for virtualization? Certainly the x86 wasn't originally designed to be an S/370 in a smaller box. I read Theo's post as raising the question of how exposed the hypervisor is to attack given the allegedly rather dicey hardware platform on which these VM programs run. He seems to suggest that virtualization might make denial-of-service attacks against the host more possible, with the consequence that a successful attack could take down all the VMs at once. But I'm not well-versed in any of these matters, so I'm relying on the collective "wisdom" of Slashdot to learn more.

Re:Perhaps a Different Train of Thought (1)

Soko (17987) | more than 6 years ago | (#21115565)

It's highly probable that Theo is right.

Theo is a very smart and resourceful individual - that's shown by his work

After reading the above post, it's highly probable he is a very abrasive and one sided individual.

That's an understatement to say the least. It's not "highly probable", it's an absolute certainty.

But this is a tech forum so I won't get into judging character.

You must be new here. ;-)

Anyway, abrasive as he is, when Theo has something to say on security I tend to listen as he has a proven track record in that regard. Think about it - if you own one virtual machine (say through a poorly secured PHP application) and can then break into the virtualization layer, you can likely own every virtual machine hosted on the physical machine or even the cluster.

I tend to agree with Theo here - so far, security (other than on a theoretical level, i.e. OS isolation) has not been completely thought out at the virtualization layer, hence there's no true security benefits to using virtual machines (other than recovery). That's what he means, I think, when he talks about "something on the shelf" - the security selling point is not really there.

Soko

Re:Perhaps a Different Train of Thought (1)

wattrlz (1162603) | more than 6 years ago | (#21115643)

I find your arguements interesting, but flawed. Not all bugs are created by some, "bad coders" sneaking into a project and plying their trade of writing bad code. If that was so every project could be perfected by handing it to a few known good coders to edit. Bugs are created from many different factors and one of them is the fact that people, no matter how skilled, make mistakes. Enough mistakes made by enough people in confluence create a bug. It is logical to assume that, since bugs do occur, there is a finite probability, greater than zero, that a bug will occur on any particular line of code. If one had an exceptionally good statistical analysis of all coding one could make statements such as, "A project with X lines of code is 95% likely to have at least Y bugs". I like the net analogy though. I think that one works well.

Theo is so full of himself he misses reality (2, Insightful)

lib3rtarian (1050840) | more than 6 years ago | (#21114769)

Theo thinks so highly of himself, he is just wrong on this one. There is not one recorded/public example of someone breaking out of the isolation of a virtual environment! I dare someone to demonstrate otherwise, and I will eat my words.

Re:Theo is so full of himself he misses reality (1)

mccalli (323026) | more than 6 years ago | (#21114839)

There is not one recorded/public example of someone breaking out of the isolation of a virtual environment! I dare someone to demonstrate otherwise, and I will eat my words.

VMware Tools seems to do it every day...

Cheers,
Ian

Re:Theo is so full of himself he misses reality (1)

644bd346996 (1012333) | more than 6 years ago | (#21115425)

That's a feature, not a bug. The existence of that hole is well-documented and intentional (even if the details of exploiting it aren't). I haven't used VMware, so I can't comment on whether that feature can be disabled by the user, but it would be trivial for VMware to do so.

Re:Theo is so full of himself he misses reality (0)

Anonymous Coward | more than 6 years ago | (#21114859)

Yeah, but can they break into a virtual enviroment? That's more of a problem.

Re:Theo is so full of himself he misses reality (1, Informative)

Anonymous Coward | more than 6 years ago | (#21114871)

There is not one recorded/public example of someone breaking out of the isolation of a virtual environment! I dare someone to demonstrate otherwise, and I will eat my words.

Start eating. There have been documented & patched bugs in VMware where the actions of the client VM can crash or exploit problems in the host.

That being said, VMware is the most solid virtualization product for the PC architecture.

Re:Theo is so full of himself he misses reality (2, Informative)

LLuthor (909583) | more than 6 years ago | (#21114939)

Lots of hypervizors and VM kernels are vulnerable, and can allow guest OSes to inject code into the host OS.

See this for just a few examples: http://secunia.com/advisories/26890 [secunia.com]
I can easily find several implementations that cause DOS and escalation attacks on older versions (these are fixed in the current versions, but you can bet more flaws will be found).

Regardless of Theo's opinion of himself, he is right in that more complexity means more bugs.

Re:Theo is so full of himself he misses reality (1)

Stipe (35684) | more than 6 years ago | (#21115313)

> Regardless of Theo's opinion of himself, he is right in that more complexity means more bugs.

That more complexity means more bugs I agree with. However:

  • While the points of interaction are probably more complex (virtualizing interrupts, memory faults), there is a smaller number than in the typical kernel interface - so it's not clear whether the overall complexity is larger or smaller.
  • The amount of code in a typical kernel includes many device drivers and other such features (filesystems, etc), which must all be written correctly. A Virtualization layer is providing a simpler set of primitives (block devices rather than filesystems), so there's likely to be less code.
  • VM code is much less mature and hasn't had the security focus that OS's have. Unix-like OS's have been around for best part of 30 years, virtualization on x86 for, what, 10 years? Figures that Virtualization has had less security-related scrutiny (and almost certainly less than OpenBSD)
So I think there's potentially less code to be worried about in virtualization, but the code that is is still prone to security bugs, just the way page faults and the like are in conventional kernels. The lack of noise that's been made about virtualization security (until now) is a sign to pessimissists (or just those that are experienced) that it's not had the thorough peer review and battering that most OS kernels have. There's potential there for a smaller codebase to be worried about (thus more security), but in the short term, it's an unknown factor, which translates to less security. Long term, I think virtualization is a win, but there's no shortcut to a secure system.

Re:Theo is so full of himself he misses reality (1)

Cheesey (70139) | more than 6 years ago | (#21115013)

Here is one [securitytracker.com] .

Beware of a false sense of security! VMware was not designed to be a security tool.

Re:Theo is so full of himself he misses reality (1)

Krondor (306666) | more than 6 years ago | (#21115057)

There is not one recorded/public example of someone breaking out of the isolation of a virtual environment! I dare someone to demonstrate otherwise, and I will eat my words.

How do those words taste? [eweek.com] .

From the link: "It could allow a malicious hacker to sidestep the virtual machine and exploit the underlying operating system.".

Anyway I think that you do make a point. Exploiting the underlying OS isn't as much as exploiting the guest OS in the virtual instance. Interesting stuff like Blue Pill [blogspot.com] (which is hotly debated in security circles ATM), poses unique risks to virtual environments.

Still, I would say Theo is dead on. Virtualization makes a lot of sense, but that doesn't mean you should assume you gain anything from a security perspective. Think of it this way. Every layer of complexity in your environment adds another attack vector... Virtualizing an operating system provides an additional complexity over running the same operating system native. Makes sense to me that there would be additional security concerns. Even Intel VT itself has been proposed as a source of potential security concern.

Attention Grabbing (0)

Anonymous Coward | more than 6 years ago | (#21114831)

This guy is just grabbing for attention. Anyone in IT already knew there will be security issues when introducing a Hypervisor, but it doesn't make your hosts/lpars any less or more secure. A good IT admin designs systems to be secure by identifying potential security risks and minimizes them and there is no reason to let this clown spread FUD that might inhibit a fast growing technology advancement.

I'll make a bold statement that hypervisors make systems MORE secure because they obscure the hardware layer and allow for cleaner more efficient drivers to be installed uniformly on your accessable hosts.

Re:Attention Grabbing (1)

ben kohler (1109391) | more than 6 years ago | (#21115045)

This guy is just grabbing for attention.
wait, did theo submit the story to /.?

VMware selloff (1, Funny)

Anonymous Coward | more than 6 years ago | (#21114833)

Thanks for the insider tip Theo, I just dumped all of my VMware stock.

Missing the point (1, Interesting)

Anonymous Coward | more than 6 years ago | (#21114885)

Virtualization layers, and their cousins Separation Kernels are the darlings of the security crowd because they can be written in a relatively small number of SLOCs, which means there is a possibility to formally analyze them. Where Formal Analysis means proofs written in a well established mathematical notation, and machine checked. Green Hills Software has a separation kernel that should shortly be certified to a very high level (EAL 6 Augmented) CCEVS [niap-ccevs.org]

What are the big threats now? (2, Interesting)

timeOday (582209) | more than 6 years ago | (#21114895)

A few years ago, it seemed email worms were constantly ravaging Outlook. That, I noticed. But that seems to have tapered off. Haven't noticed any panicked patching of zlib or ssh or sendmail lately. What is keeping people busy these days? Spyware-infested zombie boxes? Anything else?

Re:What are the big threats now? (2, Funny)

zappepcs (820751) | more than 6 years ago | (#21115171)

The number one threat to America today? BEARS !

Re:What are the big threats now? (1)

somersault (912633) | more than 6 years ago | (#21115661)

I think the latest is something called "World of Warcraft".

Risk profiles (5, Insightful)

Anonymous Coward | more than 6 years ago | (#21114919)

Let's consider the following:
  1. Security is improved by minimizing the number of services your software layer exports.
  2. Virtualization has a relatively small, well-defined number of services.
  3. Operating systems do not.
  4. ???

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:Risk profiles (1)

Aladrin (926209) | more than 6 years ago | (#21115491)

I think you missed the point.

App A may be secure, but probably is not.
App B may be secure, but probably is not.

If you run BOTH, you're even less likely to be secure.

It's the same here. OS A is insecure. To 'secure' it, you run it under Virtualization, which is itself possibly insecure. You've now got all the insecurity of OS A and all its apps plus the Virtualization to worry about.

If Virtualization covered up the problems with the OSs it hosts, there would be no issue. It does not.

Topic is x86 Virtualization (1)

swamp boy (151038) | more than 6 years ago | (#21114933)

From TFA,

The topic is specifically about virtualization on the x86 platform.

Re:Topic is x86 Virtualization (0)

Anonymous Coward | more than 6 years ago | (#21115173)

Wanna sell me an AIX boy?

Useless (3, Interesting)

andreyw (798182) | more than 6 years ago | (#21114947)

Theo's side keeps asserting that "x86 virtualization isn't secure", but they seem to be perfectly comfortable at keeping the discussion at the level of a "I'm right, NO I'M RIGHT", without any corroborating statements (Hint: Theo's "I am familiar with x86 and its 'nastiness'" isn't one). What's not secure about SVM? What's not secure about VT-x? Why does Theo think that virtualizatio somehow has to imply legacy PC I/O emulation?

Ugh.

Re:Useless (4, Interesting)

Krondor (306666) | more than 6 years ago | (#21115429)

What's not secure about SVM? What's not secure about VT-x?

VT-x and SVM provide paths for rootkits to integrate and hide. New rootkits like Blue Pill [bluepillproject.org] and Vitriol [theta44.org] utilize SVM and VT-x to virtualize the host platform and remain undetected and immune from removal. They're not widespread, but an attack vector exists, which implies the security concerns over them.

Makes sense to me.

Re:Useless (0)

Anonymous Coward | more than 6 years ago | (#21115577)

Isn't that more of an argument against an OS on the bare hardware? The rootkit can take over the hardware, and running the OS in a VM it controls.

But, if there is already a hypervisor in place, this attack vector is gone.

Re:Useless (1)

the_B0fh (208483) | more than 6 years ago | (#21115667)

That's because you didn't follow the rest of the thread. Hint: That was just one email in a hundred+ long chain of emails.


Also - how the hell do you do virtualization without virtualizing legacy PC I/O emulation? And emulating all the assorted crap from the early 80s?! Hello, IRQs anyone? Just because there's now a layer of crap on top, hiding the old crap does not mean the old crap is not there.


And, lets say you have a guest, running a secure operating system, in a VM. And you have windows in another VM. Windows get rootkitted. And a guest->host escalation happens. The attacker now has full access to your secure OS's memory space! It doesn't matter even if you encrypt everything - the attacker has full access to your memory space! Not only that - any type of security you have in place can be easily thwarted. Hell, the attacker can just map any checks you have to NOPs, and you would not be any wiser.

Re:Useless (1)

tji (74570) | more than 6 years ago | (#21115733)

Yes, precisely. He doesn't say that he has looked into virtualization code and it has X problems. Or, even virtualization is vulnerable to Y attacks. He says "Those of us who have experience with the gory bits of the x86 architecture can clearly say
that we know what would be involved in virtualizing it, and if it was so simple, we would not still be fixing bugs in the exact same area in our operating system going on 12 years."

In other words "I've never really studied the problem. But my guess is that this is hard."

The thing is, his premise looks correct. You don't somehow gain security by moving from physical hosts to combining them as VMs on a single hypervisor. You gain a ton of other efficiencies, but you don't actually gain in security. Some of the examples cited as gaining in security were really just operations improvements afforded by easier separation of VMs as compared to physical hosts.

The question is: how much security do you lose? For most practical purposes, it's not enough to dissuade people from virtualization.

Unfortunately, his message is obscured by the childish way in which he presents it.

I'm Not Sure I Buy His Analysis (5, Interesting)

Nova Express (100383) | more than 6 years ago | (#21114985)

The snippet presented seems to suggest that more security holes in virtualization = less secure operating system, or OS(X) + V(X), where OS(X) represents the operating system vulnerabilities and V(X) represents virtualization vulnerabilities.

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?

Re:I'm Not Sure I Buy His Analysis (1)

Cheesey (70139) | more than 6 years ago | (#21115201)

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?

I think you might be assuming that the security provided by the OS and the VM are multiplicative, that the result of having both is much stronger than the sum of the two parts. But that might not be true, because an attacker does not have to compromise both systems at the same time. He can attack the OS, get control of that, then use it as a launch pad to hit the VM.

Others have argued that the VM will be more secure than the OS because it is smaller and simpler, and in general I think that is a good argument. Less code = less bugs. But VMware was not designed as a security tool, and it is actually very large because it contains reverse drivers for virtual hardware (Ethernet and VGA, for example). Bugs in this code could be serious security problems (example [securitytracker.com] ). To take another example, the QEMU VM lets you use SLIRP as a quick and dirty way to get networking running. But SLIRP is notoriously filled with security bugs. It's useful, but it's not designed to be secure, and if you use it, QEMU can't stop malicious programs escaping the VM through SLIRP.

Re:I'm Not Sure I Buy His Analysis (1)

mdielmann (514750) | more than 6 years ago | (#21115285)

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?
What you are missing is that hackers with different skillsets might talk to each other. This is similar to defeating DRM, another security model. Once it's broken by one person, there's nothing to stop him from sharing it with everyone else.

Re:I'm Not Sure I Buy His Analysis (1)

jon_anderson_ca (705052) | more than 6 years ago | (#21115483)

where OS(X) represents the operating system vulnerabilities

I have a box here addressed to you from one M.Fanbois... it's ticking... shall I open it for you?

Straw man argument (1)

ToasterMonkey (467067) | more than 6 years ago | (#21115673)

I wouldn't be very concerned with Theo's rant. I don't believe the industry at large is pushing VMs as a security solution. Vmware [vmware.com] doesn't even mention it as a reason for virtualization, and they sure as hell would if it was a good one. Maybe security is used as a pitch elsewhere, who knows. Somewhere this thing snowballed into a straw man, from the actual posts, to kerneltrap, to Slashdot, we get "Virtualization Decreases Security"... *facepalm* It gets harder and harder to read Slashdot every day.

This started when a guy on his message list suggested that OpenBSD get a Xen port and believed [kerneltrap.org] "Virtualization seems to have a lot of security benefits."

Theo responds [kerneltrap.org] by insulting him, then downplaying virtualization as if it were some kind of toy.

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.
Further down the postings, you get a better idea of what Theo's opinion of VMs.

If people were saying:

        "Yes, it increased hardware utilization, and the nasty
        security impact might be low"

it would be fine.

But instead we have many uneducated people saying:

              "Yes, it increased hardware utilization, and it improved security too".

And that's complete and utter bullshit.
All that can be taken from this silly "news" here on Slashdot is that NOBODY had better use security as an excuse to weasel something past Theo de Raadt. He apparetnly has a very good nose for both weasels and security.

But it's so fun (1, Funny)

Anonymous Coward | more than 6 years ago | (#21115031)

You mean my strategy of running Windows inside of Mac Parallels inside of Pear inside a VMWare instance in a Wine bottle isn't the most secure, stable environment ever conceived? Sheeze. Maybe I should just get a Mac. :)

--
http://www.metagovernment.org/ [metagovernment.org]
GOVERNMENT BY *ALL* THE PEOPLE

You're not complicating it enough (0)

Anonymous Coward | more than 6 years ago | (#21115305)

It would be OK if you accessed the whole thing through an X-window running on a VirtualPC instance of Debian inside a Win 2000 shell.

Re:You're not complicating it enough (0)

Anonymous Coward | more than 6 years ago | (#21115489)

...through a OpenBSD VNC server onto an Ubuntu-based terminal server, accessed on a Mac through VPN...

Theo rocks, as his usual! (3, Funny)

VincenzoRomano (881055) | more than 6 years ago | (#21115063)

And as there is no engineer that can develop hardware without security bugs, the only solution is to stay with insecurity!

Sounds to me like "those who can't, bitch" (2, Interesting)

RLiegh (247921) | more than 6 years ago | (#21115105)

This sounds suspiciously close to his comments about journaling filesystems when asked why OpenBSD didn't support them (which boiled down to "journaling sucks, use softdeps instead"). OpenBSD has native support for exactly zero virtualisation schemes, whereas NetBSD has native Xen support (something Opensolaris is working on -if they don't have it already), FreeBSD and Linux both have support for kqemu and Linux and Windows both have support for VMWare, Virtualbox and kqemu.

For fuck's sake, OpenBSD can't even offer a modern version of WINE in their ports (the one they offer is from 1999, and is broken to boot).

So instead of fixing OpenBSD so that it has native support for running some sort of native virtualisation scheme, Theo does what he usually does -bitches, whines and blames the technology for the flaws in his OS.

When a Port is Lagging Behind the Mainstream (2, Informative)

shking (125052) | more than 6 years ago | (#21115485)

For fuck's sake, OpenBSD can't even offer a modern version of WINE in their ports (the one they offer is from 1999, and is broken to boot)

The ports tree is 3rd party stuff, not OpenBSD. Why don't YOU contribute instead of whining.

When a Port Is Lagging Behind the Mainstream Version [openbsd.org]

"The ports collection is a volunteer project. Sometimes the project simply doesn't have the developer resources to keep everything up-to-date. Developers pretty much pick up what they consider interesting and can test in their environment."

"If you really need a new version of a port, you should ask the MAINTAINER of the port to update the port....if you can send patches for this, all the better. To create proper patches, you should refer to the documentation on building ports."

Re:Sounds to me like "those who can't, bitch" (1)

ltjohhed (231735) | more than 6 years ago | (#21115525)

It's all strategy. When you can't run anything, you're as secure as you'll ever be!

Re:Sounds to me like "those who can't, bitch" (1)

MikeBabcock (65886) | more than 6 years ago | (#21115557)

He has a point inasmuch as adding complexity invariably adds security issues that need addressing. However, auditing the Xen code makes much more sense considering the possible security benefits in the long run than avoiding it altogether. Partitioning of the system's resources is a net win for me.

credibility? (4, Insightful)

Known Nutter (988758) | more than 6 years ago | (#21115153)

Theo's childish, condescending and pointless choice of language seems to undermine his credibility. Although he may be an authority on the subject, I think he owes it to himself - as well as the rest of the community he helped to create - to communicate in a more professional, civilized and respectful manner.

He's in the same bucket as Dvorak - who wants to listen to the little twerp?

Its not just the developers... (1)

rodney dill (631059) | more than 6 years ago | (#21115209)

I do a lot of prototyping and testing out of scenarios with virtual machines. (40+ iterations for servers and client) Not all are complete builds as I do a lot of cloning. If you fire up a virtual machine that hasn't been in use for a while, you may need to spend time with security updates. Also if you didn't place or adequately configure virus protection and a firewall in an original clone you may end up with a number of machines with poor security. On the other hand cleaning up viruses is easy with my scenario, I just delete a current clone and go back to one not infected. (Assuming the virus is readily identifiable.

Wrong argument? (1)

leuk_he (194174) | more than 6 years ago | (#21115249)

I am not sure that the argument is right. Saying that virtualizion add possible security bugs is like saying that adding a personal firewall is adding fucntionaltity and thus possible exploits.

Virtualiztaion is more secure IMHO than current process isolation in most operating systems, but both can fail.

Theo's argument about security just proves the argument of linux about Security is "people wanking around with their opinions" is not unrealstic.

You have torealize that the alternative to virtualisation is getting an extra box with hardware or run 2 application on the same box. 2 machines is more secure, second solutions sounds LESS secure.

Dumb (1)

Reality Master 101 (179095) | more than 6 years ago | (#21115273)

I have no idea with Theo's point here is. His statement is like saying, "Firewalls are programmed by the same people who write operating systems. If you think Firewalls have no security issues, then you're deluded, if not stupid." Therefore, Firewalls are useless and just increase complexity.

Virtualization, from a security standpoint, is just a firewalling method. It increases isolation between instances, and more isolation is ALWAYS good.

Blah blah blah. (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21115277)

Miss Theo is a fucking loudmouth and a bitch, who cares what he says?

unstated assumption (1)

sribe (304414) | more than 6 years ago | (#21115433)

I believe that he is working from the unstated assumption that the virtualization host and guest OSen all have approximately equivalent levels of security. If so, then virtualization does just increase the number of holes available for exploit. Rather like the way a RAID system increases the overall chance of a drive failing, because of using more drives. The difference of course, is that the RAID system is able to effectively isolate the failed drive, where a security exploit in one OS can potentially provide a path for breaching other OSen.

So his point makes sense given an assumption. But what if there were some OS "A" that was much more secure than some other OS "B". In that case, it is at least possible to increase the security of an installation of OS "B" by hosting it under "A", where "A" (and the virtualization software, which of course also needs to be much more secure), can protect it from a variety of attacks. So the question remains: what if? Hmm...

Theo's pessimism and where it comes from. (4, Insightful)

argent (18001) | more than 6 years ago | (#21115605)

Theo tends to be cynical and pessimistic about just about anything that's got to do with security, and he's got good reasons to be... things that people push as security features turn out to be irrelevant or even actually dangerous a large proportion of the time. They're not batting 1.000, or even 0.500, by any means.

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.

a google employee has done a good analysis (3, Informative)

cpm99352 (939350) | more than 6 years ago | (#21115623)

As another person pointed out on the OpenBSD list, see http://taviso.decsystem.org/virtsec.pdf [decsystem.org] for Tavis Ormandy's analysis of various VM's -- attack methods were exploiting bugs in the x86 architecture as well as invalid I/O device communication.

both sides have a point; (1)

LukeCrawford (918758) | more than 6 years ago | (#21115665)

say I have two applications that need to be run; a mailserver and a webserver, say. The most secure configuration is to have one hardware box for the mailserver, and another for the webserver; each box running nothing else.

Now, if I want to save money, I could combine both onto one box without virtualization. This is the least secure way to do it, as if someone compromized the mail server, they would only need to overcome the user-level isolation to then gain access to the mailserver.

If I want a setup that is not quite as secure as the first option, but much better than the second, I could create two virtual servers, one for the webserver and one for the mailserver; this way, if someone compromised the mailserver, they would need to overcome both the os-level protections and then find a hole in the virtualization isolation (which, from what I understand, hasn't yet happened with paravirtualized xen- HVM xen is much less secure.)

when you are running a paravirtualized xen setup, the big thing to be concerned about is the Dom0; you should never have an external IP on the Dom0, as if the dom0 is compromised, it is all over.

A lesson on mis-communication in English (0)

Anonymous Coward | more than 6 years ago | (#21115679)

After scanning that thread, I was quite amused. This is a classic example of everybody talking about something, believing they are talking about the same thing, but. . . not really. Nobody notices it because nobody states an essential premise.

We have one poster, "Lee", who states that he feels that Virtualization improves security. . . but he fails to define his point of comparison - more secure than *what*? We have other posters, Theo among them, who state that they feel Virtualization decreses security. . but they also fail to define their point of comparison - less secure than *what*?

After reading through the posts, I think what this argument comes down to is that Lee feels Virtualization improves security compared to a bunch of users sharing resources of a single computer (e.g. a shared web host, where there is a single instance of Apache on a single instance of whatever OS, and they each have their own virtual websites in seperate directories [as one example]). Particularly where you want to give those users a relative amount of freedom. From his basis of comparison, he is possibly correct (though I suppose the argument could be made that the VM is still not really any safer than a server that is properly setup to be shared by multiple users).

I think that, the argument that Theo, et. al., are trying to make though is that multiple physical servers can provide guaranteed isolation that a single server running multiple VMs cannot do. So, I think, the basis of comparison for them is that one server is not more secure than multiple physical servers, and that if you are looking at software-based security on a single machine, a software hypervisor is probably not any more secure (and, at least theoretically could be less secure) than the Operating System is. I dunno if that is true or not, as I do not have any expertise in these matters. But, in any case, I found the thread to be a fascinating example of what, appears to me, to be miscommunication, because people feel it's *obvious* what they mean, when they appear to have omitted a necessary piece of information, to me.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>