Weekly Edition
Return to the Distributions page
| |||||||||||||
Qubes 1.0 released
Version 1.0 of the Qubes
security-oriented desktop distribution has been released.
"Generally Qubes OS is an advanced tool for implementing Security by
Isolation approach on your desktop, using domains implemented as
lightweight Xen VMs. It tries to marry two contradictory goals: how to make
the isolation between domains as strong as possible, mainly due to clever
architecture that minimizes the amount of trusted code, and how to make
this isolation as seamless and easy as possible." LWN looked at Qubes in 2010.
(Log in to post comments)
Qubes 1.0 released Posted Sep 5, 2012 19:36 UTC (Wed) by einstein (subscriber, #2052) [Link]
"lightweight xen VMs" still consume far more resources than need be. Ideally this concept could be implemented using containers, which would make a lot more sense IMHO. A container has practically no overhead, zero resource usage when idle, and provides essentially bare metal performance levels when the resources are available.
Qubes 1.0 released Posted Sep 5, 2012 22:04 UTC (Wed) by ibukanov (subscriber, #3942) [Link]
Qubes Architecture Specification at http://qubes-os.org/Resources.html describes that Qubes does not create VM per application. Rather it setups few (like 5 or less) VMs for application domains like VM for browsing untrusted sites, VM for email and&or social networks, VM for internet shoping where one enters the credit card number, VM for work-related applications.
Given that the root filesystem is shared among VMs (using a signed read-only block device with copy-on-write support to deal with Linuxes that cannot mount the root purely read-only), the setup is not heavy on resources and is significantly more secure than the container-based approaches.
Qubes 1.0 released Posted Sep 5, 2012 22:27 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> ...and is significantly more secure than the container-based approaches.
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) [Link]
> that depends on what you consider a problem.
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.
Qubes 1.0 released Posted Sep 5, 2012 23:46 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> A proper compare is about hypervisor + part of the kernel it uses versus container code + full kernel
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)
Qubes 1.0 released Posted Sep 6, 2012 9:35 UTC (Thu) by ibukanov (subscriber, #3942) [Link]
> you are leaving out the separate kernel running in the VM, it can have it's own vulnerabilities.
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.
Qubes 1.0 released Posted Sep 7, 2012 9:26 UTC (Fri) by lindi (subscriber, #53135) [Link]
> you are leaving out the separate kernel running in the VM, it can have it's own vulnerabilities.
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.
Qubes 1.0 released Posted Sep 7, 2012 18:33 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
vulnerabilities in the VM kernel absolutely matter.
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"
Qubes 1.0 released Posted Sep 7, 2012 18:44 UTC (Fri) by lindi (subscriber, #53135) [Link]
You have a point. However, not all VMs in Qubes are connected to a network.
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.
Qubes 1.0 released Posted Sep 6, 2012 1:20 UTC (Thu) by richarson (subscriber, #74226) [Link]
Actually, you don't *have* to use one VM per app but you *can* do it if you are sufficiently paranoid and have the resources (memory, mostly).
Check for example:
http://theinvisiblethings.blogspot.com/2011/03/partitioni...
Cheers
Qubes 1.0 released Posted Sep 6, 2012 2:28 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
remember the question was which is better.
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.
Qubes, Xen vs containers Posted Sep 8, 2012 14:25 UTC (Sat) by davecb (subscriber, #1574) [Link]
That was the experience of the Solaris developers: they wanted a secure and lightweight mechanism, so they adapted code that was already in the kernel to provide security isolation and simplified it to produce the appearance of virtual machines.
The initial solaris "zones" were extremely lightweight, since their code paths were already being executed. And they had their security designed in from (before!) the beginning.
They were then extended with resource management to create full "containers".
Right from the beginning, they were simple and elegant, and adding the third generation of resource controls didn't mess them up at all (:-))
From that experience, I think a distribution with Linux containers would be a particularly good base from which to create a secure desktop.
--dave
|
|||||||||||||