Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
that depends on what you consider a problem.
a container based system where every app is in a separate container (sharing no files) would be considerably more secure than having several apps in each VM.
The only way the container would be less secure is if you think that there are more likely to be vunerabilities in the container code than in the VM hypervisor code + the kernel used in the VM
different people will come down differently on this question, so it's far from clear that a small number of VMs are the 'right' answer.
Qubes 1.0 released
Posted Sep 5, 2012 22:55 UTC (Wed) by ibukanov (subscriber, #3942)
That paper explicitly states the reasons for isolating app domains rather than apps. So surely it all depends on the security needs, but I agree with the authors that for a common setup app domains should work.
> The only way the container would be less secure is if you think that there are more likely to be vunerabilities in the container code than in the VM hypervisor code + the kernel used in the VM
A proper compare is about hypervisor + part of the kernel it uses versus container code + full kernel as typically containers do not isolate the hardwire drivers from the rest of the system. Given the efforts Qubes guys spent to minimize the hypervisor and the kernel part (network and storage drivers are run in untrusted VM), the container-based approaches would have significantly more kernel code and, as such, vunerabilities.
Posted Sep 5, 2012 23:46 UTC (Wed) by dlang (✭ supporter ✭, #313)
you are leaving out the separate kernel running in the VM, it can have it's own vulnerabilities.
I think it's debateable over which has the most code, but also which has the more tested code.
And while 'proper' and 'careful' selection of apps to share vulnerabilities with can minimize the interactions of those vulnerabilities, making such a selection is very hard, and is very likely to change over time as apps grow new features.
It's very clear that we disagree over which is worse, but I think the important thing is to recognize that there is not 'one true answer', and especially the fact that what was true at some point in the past may not still be true today (let alone tomorrow)
Posted Sep 6, 2012 9:35 UTC (Thu) by ibukanov (subscriber, #3942)
However this kernel is contained by VM and a bug there should not harm other VMs which is not the case with containers. Plus with the Qubes design an infected VM cannot have a permanent rootkit installed as a VM reboot brings clean kernel image and the root filessytem.
> making such a selection is very hard, and is very likely to change over time as apps grow new features.
This applies IMO to the containers as well as there one has to define new rules for evolving applications to allow them to inteact with each other.
> that there is not 'one true answer',
That is very true. However, within the given constrains one approach at a particular moment can win.
For example, one a relatively resource constrained system without IO and harware virualization features containers are a clear win especially if one has option to define the application API from scratch and apps and libraries are typically written in a type-safe language. Android is a good example of that. It also demonstrates how sound container-based foundation allows to adapt the system to new harware with minimal efforts.
On the other hand if the goal is to run the current native desktop applications that need to iteract with each other using the established API and that run on standard hardware, then VM and app domains are the winner IMO at this moment.
Posted Sep 7, 2012 9:26 UTC (Fri) by lindi (subscriber, #53135)
I don't think vulnerabilities in the VM kernel matter. There is no root password so malicious code in a VM can just switch to root and load a kernel module, right? Qubes does not depend on the security of the kernel that runs inside the VM.
Posted Sep 7, 2012 18:33 UTC (Fri) by dlang (✭ supporter ✭, #313)
If the kernel that's run inside the VM is vulnerable to a remote exploit, you just loop through all the VMs and exploit it's kernel to take over that VM.
the fact that it's a separate kernel from the main OS kernel can be an advantage or disadvantage, depending on how stripped down it is and how it's upgraded.
I've seen too many people think that VMs never need to be upgraded and so they end up running old, vulnerable versions of things inside the VM because "virtualization solves the security problem"
Posted Sep 7, 2012 18:44 UTC (Fri) by lindi (subscriber, #53135)
The VMs that are connected typically have a firewall (running in a separate VM too) with a policy that limits the incoming traffic. Software can always have bugs but local root vulnerabilities are much more common than remotely exploitable bugs against a system that only runs firewall and offers no services.
Posted Sep 6, 2012 1:20 UTC (Thu) by richarson (subscriber, #74226)
Check for example:
Posted Sep 6, 2012 2:28 UTC (Thu) by dlang (✭ supporter ✭, #313)
I agree that a full VM isolation is better than container isolation
However I also say that separating ever app is more secure than only splitting them into different bundles.
If you don't have the resources to run full VM isolation, are you better off with VM isolation in bundles, or full container isolation?
even partial VM isolation will take more resources than container isolation, how much more depends on a lot of factors.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds