Slashdot Log In
Virtualization Decreases Security
Posted by
kdawson
on Thu Oct 25, 2007 10:54 AM
from the more-chances-to-blow-it dept.
from the more-chances-to-blow-it dept.
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."
Related Stories
Firehose:Virtualization Decreases Security by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
Virtualization Decreases Security
|
Log In/Create an Account
| Top
| 340 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Uh oh (Score:5, Funny)
Re:Uh oh (Score:4, Funny)
Re:Uh oh (Score:5, Insightful)
(http://www.sbyrne.org/)
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 (Score:5, Insightful)
(http://blog.godshell.com/)
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:Uh oh (Score:5, Informative)
(Last Journal: Sunday September 16, @11:18PM)
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
History teaches once again... (Score:1, Interesting)
(http://tsfraser.googlepages.com/index.html)
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... (Score:4, Funny)
(http://slashdot.org/)
Re:History teaches once again... (Score:4, Informative)
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... (Score:4, Insightful)
(http://tsfraser.googlepages.com/index.html)
Re:History teaches once again... (Score:5, Informative)
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... (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:History teaches once again... (Score:5, Insightful)
(http://slashdot.org/)
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... (Score:5, Funny)
Indeed. Implementing proper security is no small potatoes.
Welcome to the rest of the IT world, Theo! (Score:1)
(http://www.sacredsoulrecords.com | Last Journal: Thursday July 03 2003, @05:17PM)
Re:Welcome to the rest of the IT world, Theo! (Score:5, Insightful)
(Last Journal: Tuesday August 07, @01:18PM)
Counterargument (Score:3, Insightful)
Perhaps a Different Train of Thought (Score:5, Insightful)
(http://slashdot.org/~eldavojohn/ | Last Journal: Tuesday October 16, @03:26PM)
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.
Re:Perhaps a Different Train of Thought (Score:5, Informative)
Theo is so full of himself he misses reality (Score:2, Insightful)
VMware selloff (Score:1, Funny)
Missing the point (Score:1, Interesting)
What are the big threats now? (Score:3, Interesting)
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.
Topic is x86 Virtualization (Score:1)
The topic is specifically about virtualization on the x86 platform.
Useless (Score:4, Interesting)
(http://andreywarkentin.livejournal.com/)
Ugh.
Re:Useless (Score:5, Interesting)
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.
I'm Not Sure I Buy His Analysis (Score:5, Interesting)
(http://home.austin.rr.com/lperson/ | Last Journal: Saturday July 16 2005, @01:52PM)
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?
But it's so fun (Score:1, Funny)
--
http://www.metagovernment.org/ [metagovernment.org]
GOVERNMENT BY *ALL* THE PEOPLE
Theo rocks, as his usual! (Score:4, Funny)
Sounds to me like "those who can't, bitch" (Score:2, Interesting)
(http://slashdot.org/ | Last Journal: Sunday July 29, @04:31PM)
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.
Re:When a Port is Lagging Behind the Mainstream (Score:4, Insightful)
(http://slashdot.org/ | Last Journal: Sunday July 29, @04:31PM)
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.
credibility? (Score:4, Insightful)
He's in the same bucket as Dvorak - who wants to listen to the little twerp?
Its not just the developers... (Score:2)
(Last Journal: Sunday November 02 2003, @01:54PM)
Wrong argument? (Score:2)
(http://emulemorph.sourceforge.net/)
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 (Score:2)
(http://slashdot.org/ | Last Journal: Thursday November 01, @12:01PM)
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.
unstated assumption (Score:2)
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. (Score:5, Insightful)
(http://www.scarydevil.com/~peter/ | Last Journal: Monday September 26 2005, @06:53PM)
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 (Score:3, Informative)
both sides have a point; (Score:1)
(http://prgmr.com/~lsc | Last Journal: Friday June 09 2006, @06:50PM)
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.
Okay, here's what happened (Score:3, Informative)
(http://www.faqs.org/rfcs/rfc3675.html)
Theo de Raadt argues that it's more secure to put applications on separate machines than to consolidate them into a single machine.
L. V. Lammert very inarticulately argues that having a VM provides more security, because otherwise, you're not going to put applications on separate machines, because it's too expensive.
Security == managing complexity (Score:5, Interesting)
Here's the first truth of security: your ability to secure a system is INVERSELY PROPORTIONAL to the size of the interface to that system. Every interface point is a potential attack vector, whether direct (an attacker can exploit the interface) or indirect (something outside your control is loaded at interface A, then an attacker at interface B causes A to exploit something). Most security products try to reduce the size of interfaces (e.g. a firewall limits the number of open ports, then further excludes some types of traffic from those ports).
Look at a general purpose operating system kernel. There are hundreds of system calls (direct attack vectors), hundreds more driver interfaces (indirect attack vectors - driver interfaces are privileged and thus drivers must be bug-free), a few thousand more configuration points (Windows Registery, Linux /sys and /proc trees). Add the libraries that make up the rest of the operating system, and the number of APIs has exploded to thousands, if not tens of thousands.
Now look at a hypervisor stack. The hypervisor::guest interface is the CPU instruction set (extremely well documented and easy to programatically verify, especially when 99% of instructions can be verified to have no side effects!). Much narrower interface than a general-purpose API. The driver::hypervisor interface is narrower too, since the hypervisor only uses a lower-level interface (e.g. Xen's block device interface, VMware's SCSI interface) that happens to be simpler and better documented. Configuration API is smaller, since it only needs to manage virtual machines, not every possible combination of user-level program and device.
It's the old microkernel / monolithic kernel debate all over again, where a hypervisor is a microkernel and a general-purpose OS is a monolithic kernel, and the performance loss is small enough that companies are using it in production today. Microkernel have advantages in being easier to secure, more robust in the face of bugs ... monolithic kernels are faster. Is the smaller API (and increased security) worth the loss in performance?
Here's some security thoughts, based on actual experience with virtualization bugs.
Lack of process isolation? (Score:2)
(http://www.mightyware.com/ | Last Journal: Thursday November 08, @10:18PM)
Missing the obvious (Score:1)
I think Theo is making some unstated assumptions (Score:1)
The counter assumption is that in the absence of virtualization all the services that would have run on the VMs would just all run on the same server, then virtualization can increase security because no one service may constitute a top to bottom root exploit but some combination of them may. Of course adding the extra overhead of the VMs potentially decreases the utilization your services get from the machine. However most of the time when security is discussed it is this scenario they are talking about.
And of course the reality of what happens in the field is that there is a little of both going on. You have both server that did too many things being broken up into VMs, and clumps of smaller servers being replaced with a single larger capacity VM server.
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]
Security granularity too big (Score:3, Interesting)
(http://www.animats.com)
I'm always amazed that virtualization on x86 works at all. The architecture didn't support it, and VMware dealt with that by dynamic code patching. Then Intel and AMD both added some hardware support, but 1) incompatible between Intel and AMD, and 2) single-layer (you can't run a VM on a VM on a VM, unlike IBM mainframes, where that works quite nicely. And then there's the issue that you now have two levels of scheduler, which may or may not play well together.
But those aren't the real problems. From a security standpoint, a VM running a whole operating system is an overly large security domain. It doesn't even contain, say, exploitable PHP scripts on a server, let alone a rootkit. In fact, almost any exploit that will work on a standalone server will work on the same server inside a VM, and can cause just as much trouble on the net. Now you can have multiple corrupted VM partitions!
What we're really seeing is that server virtualization is a way to unload security worries from the server farm operator (be it a hosting company or an in-house operation) onto the user. If the server operator just gives the user an empty partition and takes no responsibility for maintaining it, it's cheaper to be a server operator. Server management is easier. But it's no more secure from the standpoint of network, user, or data protection. Too much code in one security box.
Two types of security (Score:3, Interesting)
As far as VMs and security, there are two types of security - defense against the malicious, and defense against the retarded. While VMs may not add much in the long term against the malicious (and may even expose more risk), I'd argue right now they're reasonable tools of isolation, until virtualization becomes mainstream and crackers get wise to exploiting the host machine.
They are effective, from a defense against the malicious standpoint, for isolating old platforms that you continue to need, but can't be exposed to the world. We have a proprietary tool that only runs on NT 4 (we've tried 2k, XP, etc. and no dice) that we absolutely must have at work. NT4 is no longer patched when security issues are found, and there are no longer drivers for the hardware we've had to move it to. So we run it in a VMWare VM that has no network access. Problem solved.
I'd argue that VMs are very effective on the "defense against the retarded" side. We have a shared departmental webserver here my job. I'm the main admin in my spare time. However, when they merged a bunch of groups, they made us share the box with them. Thus, management mandated they be allowed to change things as root to fit their needs - adding users, resizing LVs, fiddling with apache, etc. They kept fucking up the box and breaking our stuff. So eventually I loaded up Xen and gave them their own VM that they could break in any way they wanted. Tada - their virtual box is always screwed up, mine stays up all the time, and management is happy because we didn't need more hardware.
Arguably, the above also fits within the greater utilization purpose that I see being the big driver for virtualization. Realistically, most production boxes are far oversized for what they do. If you could stack virtual boxes on real iron to get better asset utilization, that's going to be the driving force for business, as it's a simple, quick way to reduce costs.
Networking Decreases Security! (Score:2)
(http://slashdot.org/)
Seriously. It goes a bit too far to suggest that virtualization decreases security simply because of the added accessibility or mode of operation. But it's not "untrue" either. But to ignore the benefits of virtualization because of unknown but presumed added risk would be like securing your server by removing the networking from it. Yes, there are risks, but they must be balanced against the benefits.
And as for attack angles against a virtualized server? Well, you'd just about have to compromise the host first anyway and by that time, the game is already lost. (Now if someone were stupid enough to make the virtual machine's management interfaces available to the internet, that's ANOTHER problem) But otherwise, all the same steps needed to compromise a virtual server are pretty much the same as compromising a server running directly on the hardware.
Theoretics versus the practical (Score:1)
(http://127.0.0.1/ | Last Journal: Saturday December 02 2006, @12:58PM)
However, what Theo skips over is that both NAT and virtualization are great for keeping out the riff-raff. At least on my home connection, the network traffic outside of the NAT is at least 2 packets/second of bad stuff (measured via FreeBSD 7.0's security log/emails), and inside the NAT the traffic is less than a packet/day of bad stuff (when all Winblows machines are off). I believe virtualization can do the same and keep virii/spyware/bugs/etc. contained and better monitored.
So in conclusion:
In theory, I believe Theo is right.
In practice, virtualization is probably a good thing for enterprises, just as NAT is a good thing for home users.
I am hoping that people will stop yelling at each other and realize that Theo likes everything to be practically and theoretically secure, and most of us just care that our machines are "practically secure enough." However, as botnets perhaps become more profitable, it seems that they are getting smarter, and have been using multiple exploits for quite some time, so Theo might have a point.
Once again... (Score:1)
A lot of people use virtualization to combine physical machines into one. They do this for utilization, and not for security. I can see how this might make the machines less secure, since if you hack one virtual machine, and break out of the hypervisor, you now have 20 (virtual) machines hacked.
However, there is another common way to use virtualization. A desktop user might surf the web in a virtual machine. We have been told that this enhances security. It does, using the classic "layers" solution. Not only does a hacker have to exploit the user's browser, but he also has to break out of the hypervisor. The hacker doesn't know what hypervisor he needs to break into beforehand, and his time is limited to the amount of time the user spends surfing the web. Most likely, the exploit was automated, will not break out of the hypervisor, but instead die when the hypervisor is shut down, and the hacker will never even notice. Compare that to having your machine compromised as soon as a hacker exploits one of the flaws in firefox.
With all due respect to Theo but it must be said.. (Score:2)
What Theo is really saying.... (Score:2)
Theo criticizes the security of every new technology until it's implemented into OpenBSD (I bet a quick search would show 100's of examples of this, in fact I think he said something similar about SMP when Linux first implemented it), it's part of his jealousy of the gnu/Linux system having more developers and resources than OpenBSD and his belief that only OpenBSD is secure.
*sigh* (Score:2)
Really? (Score:1)
(http://www.fsdev.net/)
In other words, THANK YOU CAPTAIN OBVIOUS!!! WE WOULD HAVE NEVER KNOWN!
He's basically correct (Score:1)
But they're rare, and the current raft of hypervisors don't rate as being possibly secure.
One area in which they fail to pass muster is in regard to their layering. From the DEC paper:
One noted security practioner (not me) has opined in private correspondence that, while "[c]learly much more than this is required (as reflected in the rest of the DEC paper), but without such a strict layering a VMM design cannot be considered a serious candidate, and is probably not worth spending time and energy on. The precise number of layers will depend on the particular design, but consistent experience over several decades indicates that for the kind of functionality in a VMM something on the order of the 16 layers in the DEC design are essential to "minimizing the complexity". A small integer number of layers is an immediate tip-off that something "smells rotten" in the design."
Such minimization of complexity is necessary to support the formal modeling and analysis that would allow you to verify that, for instance, there is no unnecessary code in the hypervisor that might be exploited by an attacker (whether deliberately inserted or not).
But, in today's world, who cares? These lessons were learned decades ago - they couldn't be relevant today...
...sarcasm off
Writing bugfree code is... (Score:1)
(Last Journal: Tuesday September 05 2006, @02:49AM)
Hmm so many posts and IBM not mentioned? (Score:2)
(Last Journal: Saturday January 06 2007, @01:13AM)
But, VM technology is old stuff. It's just the x86 people are reinventing it and sometimes poorly. Heard something like this from one of the "new VM" people, "If we have VM problems we just go ask the IBM guys what they used to do in the old days to deal with that"
Sure there's probably exploitable security bugs in many VM implementations. But that does not mean there will be exploitable security bugs in all VM implementations.
You could run a pure x86 PC emulator and I think it'll be quite safe, though rather slow
Can one really claim that it is impossible to get a virtualized machine as secure as an emulated machine (in practice anyway)?
Theo is right (Score:2)
(http://www.karastathis.org/ | Last Journal: Tuesday April 05 2005, @07:51PM)
Ideally we should run apps on dedicated boxes. Virtualisation is good for saving money and for some "virtual" security against script kiddies, newbie crackers, or your own users (or yourself). VMs can't defend you against real crackers, and in fact they will make you less secure. Do it for the money or for protecting against script-kiddies and users, but not for real security. Always use multiple boxes for various apps if you can do so.
Re:Attention Grabbing (Score:1)
Re:DRM a joke to Virtualization (Score:1)
(Last Journal: Wednesday August 14 2002, @12:33PM)
For a simple example how a DRM scheme might work: The DVD drive and the graphics card set up an encrypted data stream (basically the same way two computers set up an ssh connection through the untrusted internet), and the computer only issues commands to the drive and graphics card, and transports encrypted data from one to the other. There's no way to break this scheme just through a VM; you'll have to analyze your hardware to find out the secret keys.
Re:Aesop's Fox and the Grapes (Score:2)
(http://pitabred.dyndns.org/)
Re:See a real virtualization security hole (Score:2)
(http://pitabred.dyndns.org/)
Re:VMWare rocks but... (Score:1)