4 ms·

There is an added benefit to VMs: smaller attack surface. Your average OS kernel has an abundance of interfaces, all of which may have bugs enabling a maliciou

There is an added benefit to VMs: smaller attack surface. Your average OS kernel has an abundance of interfaces, all of which may have bugs enabling a malicious program to elevate its privileges. The OS<->hypervisor channel can be much more restricted. With containers, programs in the container are generally talking directly to the host kernel through the same interfaces as any other program, so you don't get that benefit.

mpweiher 12y ago
Again, that seems a bug in the OS(es) that should be fixed, rather than papering over it by adding yet another layer, bringing its own set of vulnerabilities. In my experience, the vulnerabilities in the different layers tend to to be cumulative rather than restrictive, due to the fact that the stuff you want to protect is in the vulnerable layer.
- throwaway7767 12y ago
  Yes, of course you can only exploit a bug if it exists :) However, all code has bugs (including security-critical ones). Minimising the attack surface of trusted elements is an important part of defense-in-depth. Xen is <150000 LoC, and a lot of that can be run in less-trusted stub domains. The linux kernel runs in the millions of lines (admittedly probably not all compiled-in, but it's still at least an order of magnitude more), and none of it can be fenced away from the sensitive bits. I'm not saying containers don't have their place. But there are benefits to full VMs in security critical infrastructure.
  - Retric 12y ago
    No Zen is ~150,000 LoC more than every OS + application it's hosting. If any of them have a significant bug someone can get inside your network. Put another way Zen can have bugs which make you venerable even if your OS and application where rock solid, but it does not add anything over simply running different applications on different physical hardware.
    - throwaway7767 12y ago
      But a bug in the OS will bite you whether you are using containers, VMs or physical servers, so it's not very relevant to the discussion. When comparing the security of containers to VMs, vulnerabilities in the OS should be out of scope. A more realistic attack scenario would be a virtual host or container server with two VMs/containers: a trusted on and an untrusted one. Assume neither has networking, but the untrusted one is running compromised software. The question is how easy is it to escalate privileges from the untrusted container/VM to the trusted one? I'd say that Xen's small code size and resulting easier auditing is a benefit here.
      - deleted 12y ago
        [deleted]
  - walterbell 12y ago
    More on the small attack surface of Xen: http://www.slideshare.net/xen_com_mgr/lfnw2014-advanced-security-features-ofxenproject http://www.slideshare.net/xen_com_mgr/lfnw2014-advanced-secu...
- walterbell 12y ago
  It is being fixed by moving some isolation from software to hardware. The options are rebooting hardware/OS/compilers/apps (Mill Computing) or disaggregating existing operating systems as has been done by Xen and Hyper-V, using CPU features from AMD, Intel and now ARM. Isolated hardware regions will become smaller: http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-i... Namespaces/containers are for trusted workloads.
- dspillett 12y ago
  > Again, that seems a bug in the OS(es) that should be fixed Granted. But unless their are glaring faults or unacceptable performance issues in the extra layer(s) you can gain some "security in depth" with each layer shielding the next and previous to an extent, reducing the potential fall-out of certain classes of bug.

mpweiher 12y ago

Again, that seems a bug in the OS(es) that should be fixed, rather than papering over it by adding yet another layer, bringing its own set of vulnerabilities. In my experience, the vulnerabilities in the different layers tend to to be cumulative rather than restrictive, due to the fact that the stuff you want to protect is in the vulnerable layer.

throwaway7767 12y ago
Yes, of course you can only exploit a bug if it exists :) However, all code has bugs (including security-critical ones). Minimising the attack surface of trusted elements is an important part of defense-in-depth. Xen is <150000 LoC, and a lot of that can be run in less-trusted stub domains. The linux kernel runs in the millions of lines (admittedly probably not all compiled-in, but it's still at least an order of magnitude more), and none of it can be fenced away from the sensitive bits. I'm not saying containers don't have their place. But there are benefits to full VMs in security critical infrastructure.
- Retric 12y ago
  No Zen is ~150,000 LoC more than every OS + application it's hosting. If any of them have a significant bug someone can get inside your network. Put another way Zen can have bugs which make you venerable even if your OS and application where rock solid, but it does not add anything over simply running different applications on different physical hardware.
  - throwaway7767 12y ago
    But a bug in the OS will bite you whether you are using containers, VMs or physical servers, so it's not very relevant to the discussion. When comparing the security of containers to VMs, vulnerabilities in the OS should be out of scope. A more realistic attack scenario would be a virtual host or container server with two VMs/containers: a trusted on and an untrusted one. Assume neither has networking, but the untrusted one is running compromised software. The question is how easy is it to escalate privileges from the untrusted container/VM to the trusted one? I'd say that Xen's small code size and resulting easier auditing is a benefit here.
    - deleted 12y ago
      [deleted]
- walterbell 12y ago
  More on the small attack surface of Xen: http://www.slideshare.net/xen_com_mgr/lfnw2014-advanced-security-features-ofxenproject http://www.slideshare.net/xen_com_mgr/lfnw2014-advanced-secu...
walterbell 12y ago
It is being fixed by moving some isolation from software to hardware. The options are rebooting hardware/OS/compilers/apps (Mill Computing) or disaggregating existing operating systems as has been done by Xen and Hyper-V, using CPU features from AMD, Intel and now ARM. Isolated hardware regions will become smaller: http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-i... Namespaces/containers are for trusted workloads.
dspillett 12y ago
> Again, that seems a bug in the OS(es) that should be fixed Granted. But unless their are glaring faults or unacceptable performance issues in the extra layer(s) you can gain some "security in depth" with each layer shielding the next and previous to an extent, reducing the potential fall-out of certain classes of bug.