Virtualization Decreases Security 340
ParaFan writes "In a fascinating story on KernelTrap, Theo de Raadt asserts that while virtualization can increase hardware utilization, it does not in any way improve security. In fact, he contends the exact opposite is true: 'You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.' de Raadt argues that the lack of support for process isolation on x86 hardware combined with numerous bugs in the architecture are a formula for virtualization decreasing overall security, not increasing it."
History teaches once again... (Score:1, Interesting)
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:Welcome to the rest of the IT world, Theo! (Score:3, Interesting)
Missing the point (Score:1, Interesting)
What are the big threats now? (Score:3, Interesting)
Useless (Score:4, Interesting)
Ugh.
I'm Not Sure I Buy His Analysis (Score:5, Interesting)
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:Uh oh (Score:1, Interesting)
After reading vitriolic posts by these two fools, RMS doesn't seem all that bad.
Sounds to me like "those who can't, bitch" (Score:2, Interesting)
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: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.
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.
Security granularity too big (Score:3, Interesting)
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.
Re:Well that would be an excellent solution... (Score:3, Interesting)
I also think that another one of Theo's point that is getting lost is that _anything_ that adds complexity also adds risk and should be considered unsafe. It may be that it adds value and is therefore worth to add and to audit but it still adds risk. This I wholly agree with, which is why I also don't see the rational behind wanting to run OpenBSD in any kind of virtualized environment unless you are a developer, tester, or researcher.
Re:Counterargument (Score:1, Interesting)
Re:Uh oh (Score:3, Interesting)
What is the difference between the popular, "by 10 Dell 2650s and slap server 2003 on all of them" or "buy 1 2650 and slap 10 server 2003s on it?" Answer? nothing other than that with the virtual server you have a layer in between the hardware and OS, which 'could' offer greater security or worse. It is up in the air right now as in my opinion Virtual environments tend to put out patches faster than windows, keeping up with Linux. You say this yourself in your last paragraph.
The fault as other posters mentioned, is not with the software, but with the security measures taken to protect the underlying Apps. Admins have been running multiple Apps on one server since the beginning of the computer era. Look at servers running Apache, samba, posfix...they are just as supseptable. Now with a VM environment you can at least split them apart and kill them. If you have actually used a VM environment like the VI clients that you get from VMware there are multiple features that actually give you a step up on traditional physical environments.
In the end it is a comfort game, if you are intelligent enough, VM environments can be waaaaay more secure than traditional bare metal installs. If you are not up on your game, you shouldnt be playing anyway. I aim for reliability and security, vs ease of use and support time. VM gives me a level of comfort with my network that I cannot get without VM.
I dont know about other people in this forum but my threat to uptime is not hackers. It is user error (viruses, deleted files, massive e-mails) and proper maintainance schedules. I properly manage my firewall, keep my patches up to date and that takes care of enough of the "malicous user" problem to make me comfortable. Since switching to VM my uptime is through the roof, costs are about the same, maintainance is a bit more complex, and hardware issues are simple and rare.
Of course what do I know I am just a biased vm user who graduated a long time ago from the winNT/redhat conspiracy theories.
Re:Well that would be an excellent solution... (Score:3, Interesting)
What can't be said is that virtualization will be as secure as running several, physical boxes (assuming there is no trust relationship between the boxes). In a virtualized scenario, a compromise on either the host or any of the guests will make it easier to attack the other guests/host. In a scenario where each machine is on separate hardware, this is not the case.
Re:Uh oh (Score:1, Interesting)
Also, you should be encripting the hard drive or they make take it with them. But that doesn't happen in a non virtualized world, so why care?
I mean, of course there are holes. But there are also holes if you don't virtualize.
Maybe it would be preferable to just encrypt the credit card numbers, just in case somebody walks out with the disks. I mean this has happened before.