> Virtualization is extremely popular, but it isn't secure, and it's actually (and when you're thinking clearly, obviously) less secure than other, existing systems.
It makes me wonder why Google uses KVM to isolate multiple tenants running stuff on their machines.
Does virtualization solve all of the world's security problems? Of course not. But it does help as an additional layer of security.
> It makes me wonder why Google uses KVM to isolate multiple tenants running stuff on their machines.
"Google does it so it must be secure" is faulty reasoning.
There are valid non-security-related reasons, for example it simplifies administration and management tasks, and it is cheaper. When you do something because someone else does things you might find neither of you know what you're doing.
Of course it's worse than just buying a separate machine for each tenant, but that's obvious isn't it? On the other hand virtualization _does_ provide better isolation than containers (or jails or zones).
> The only thing that can reduce bugs (security or otherwise) is less code.
Bugs that let you escape the host kernel from unprivileged guest userspace (which would be the case where "two things can be attacked") are exceedingly rare.
On the other hand, increasing security is not just about reducing bugs, but also about defending in depth through redundant layers, so that if something breaks (your guest kernel) there's something else to protect you (your hypervisor). That's not the case for containers, even though they run less code.
If security were just about less code, OpenBSD-specific stuff like pledge or SOCK_DNS wouldn't have any place.
> There are valid non-security-related reasons, for example it simplifies administration and management tasks, and it is cheaper. When you do something because someone else does things you might find neither of you know what you're doing.
That's not why Google uses KVM. They only use it for Google Compute Engine.
> On the other hand virtualization _does_ provide better isolation than containers (or jails or zones).
Hardware virtualiation maybe, because it usually involves less code than jails or zones.
> Bugs that let you escape the host kernel from unprivileged guest userspace (which would be the case where "two things can be attacked") are exceedingly rare.
Saying "exceedingly rare" without saying what you think is rare is worse than useless. It happens more than zero.
Give numbers.
Demonstrate exactly why you think lines of code is not proportional to bugs, or point to the specific arguments my named expert gives that you believe are wrong. Do not hand-wave this with a statement like "exceedingly rare".
> If security were just about less code, OpenBSD-specific stuff like pledge or SOCK_DNS wouldn't have any place.
pledge is much smaller than seLinux.
This is evidence that security is just about less code.
> On the other hand, increasing security is not just about reducing bugs, but also about defending in depth through redundant layers, so that if something breaks (your guest kernel) there's something else to protect you (your hypervisor). That's not the case for containers, even though they run less code.
Increasing security is about understanding what you're doing. More code means less understanding.
If your mail server is broken because of bugs in your mail server, or bugs in your hypervisor, then there are two codebases with an attack-surface not one.
Users don't care: If mail is delayed or destroyed, they get angry. They don't care if it was a bug in the hypervisor or a bug in the mail server, or a bug in a web server on a nearby container or a nearby virtual machine. That increased codebase meant an increased risk (demonstrated) which means more angry users.
Thinking about keeping mail server bugs in the mail server is a red herring; it just isn't important to users, so this isn't how you should evaluate "security."
Sure. I've been working on KVM for 7 years, and I only recall two really serious vulnerabilities:
1) one bug that let you escape into the guest kernel from unprivileged guest userspace (CVE-2010-0306 and CVE-2010-0419). Even that one required relatively special circumstances, so that in practice the only exploitable user program was the X server, but this is not a bug you want to have in your hypervisor.
2) one bug that let you escape the host kernel from the guest kernel (CVE-2014-0049). Also very hard to exploit, but doable.
The "memory sinkhole" problem does not apply to virtualization.
> > If security were just about less code, OpenBSD-specific stuff like pledge or SOCK_DNS wouldn't have any place.
>
> pledge is much smaller than SELinux
It's still >0 lines of code. (BTW, comparing pledge and SELinux is apples and oranges).
> If your mail server is broken because of bugs in your mail server, or bugs in your hypervisor, then there are two codebases with an attack-surface not one.
If you place mail+web server on the same machine without a hypervisor, things can certainly be less secure than if you place multiple services on the same machine separated by the hypervisor. In the first case, breaking the web server results in a direct attack to the mail server. In the second case, after breaking the web server you still need to go against the smaller attack surface of the hypervisor.
> Thinking about keeping mail server bugs in the mail server is a red herring; it just isn't important to users, so this isn't how you should evaluate "security."
It's about keeping web server bugs in the web server, and not have them infect the mail server.
> I only recall two really serious vulnerabilities.
Having a discriminating memory doesn't help you build programs that have no bugs. It only helps you feel better about the bugs in the programs you create. Meanwhile, real users believe DoS are serious vulnerabilities.
> If you place mail+web server on the same machine without a hypervisor, things can certainly be less secure than if you place multiple services on the same machine separated by the hypervisor.
No. It isn't certain. The hypervisor is just more code. Why should anyone believe more code is going to produce less bugs?
> The "memory sinkhole" problem does not apply to virtualization.
Why do you think so?
Users believed they could "place multiple services on the same machine separated by the hypervisor" would be more secure, and then it turned out they couldn't. If only they had used a simpler system they would have had actual security. This is evident.
> It's about keeping web server bugs in the web server, and not have them infect the mail server.
Wrong. A bug in the Linux PCI code affects web servers. A bug in ext4 affects a mail server. Don't you get it? Big programs have bugs.
> But it does help as an additional layer of security.
You don't add security; you multiply the insecurity (think of traditional component reliability calculation; a system that consists of one component with 50% reliability and another component with 50% reliability is not 100% reliable, but 25%).
You can also think of virtualization in terms of redundancy. If you can break out of userspace and into the kernel, you now have to break out of the hypervisor (which has a smaller attack surface) in order to escape a very constrained environment. And by hypervisor I really mean the kernel module, because the device emulation is also running heavily constrained through pledge/seccomp/SELinux/whatever.
It makes me wonder why Google uses KVM to isolate multiple tenants running stuff on their machines.
Does virtualization solve all of the world's security problems? Of course not. But it does help as an additional layer of security.