5 ms·

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

by bonzini 10y ago

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

_pmf_ 10y ago
> 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%).
- bonzini 10y ago
  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.
geocar 10y ago
> But [virtualization] does help as an additional layer of security. This is completely wrong: Instead of one big complex code surface, now you have two. Two things that can be attacked; two things that can have bugs. Two codebases written by people who aren't thinking about reducing bugs and aren't thinking about security. That's insane. The only thing that can reduce bugs (security or otherwise) is less code. DJB did a great presentation on this subject: https://cr.yp.to/qmail/qmailsec-20071101.pdf https://cr.yp.to/qmail/qmailsec-20071101.pdf > 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.
- bonzini 10y ago
  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.
  - geocar 10y ago
    > 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. * http://www.cvedetails.com/product/19922/Redhat-KVM.html?vendor_id=25 http://www.cvedetails.com/product/19922/Redhat-KVM.html?vend... * https://xenbits.xen.org/xsa/ https://xenbits.xen.org/xsa/ * https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-20406/Oracle-Vm-Virtualbox.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p... * http://www.cvedetails.com/product/27105/Linuxcontainers-LXC.html?vendor_id=13134 http://www.cvedetails.com/product/27105/Linuxcontainers-LXC.... * https://www.blackhat.com/us-15/briefings.html#the-memory-sinkhole-unleashing-an-x86-design-flaw-allowing-universal-privilege-escalation https://www.blackhat.com/us-15/briefings.html#the-memory-sin... 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."

by bonzini 10y ago

_pmf_ 10y ago

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

bonzini 10y ago
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.

geocar 10y ago

> But [virtualization] does help as an additional layer of security. This is completely wrong: Instead of one big complex code surface, now you have two. Two things that can be attacked; two things that can have bugs. Two codebases written by people who aren't thinking about reducing bugs and aren't thinking about security. That's insane. The only thing that can reduce bugs (security or otherwise) is less code. DJB did a great presentation on this subject: https://cr.yp.to/qmail/qmailsec-20071101.pdf https://cr.yp.to/qmail/qmailsec-20071101.pdf > 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.

bonzini 10y ago
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.
- geocar 10y ago
  > 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. * http://www.cvedetails.com/product/19922/Redhat-KVM.html?vendor_id=25 http://www.cvedetails.com/product/19922/Redhat-KVM.html?vend... * https://xenbits.xen.org/xsa/ https://xenbits.xen.org/xsa/ * https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-20406/Oracle-Vm-Virtualbox.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p... * http://www.cvedetails.com/product/27105/Linuxcontainers-LXC.html?vendor_id=13134 http://www.cvedetails.com/product/27105/Linuxcontainers-LXC.... * https://www.blackhat.com/us-15/briefings.html#the-memory-sinkhole-unleashing-an-x86-design-flaw-allowing-universal-privilege-escalation https://www.blackhat.com/us-15/briefings.html#the-memory-sin... 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."