Researcher Releases Hardened OS "Qubes"; Xen Hits 4.0

Trailrunner7 writes "Joanna Rutkowska, a security researcher known for her work on virtualization security and low-level rootkits, has released a new open-source operating system meant to provide isolation of the OS's components for better security. The OS, called Qubes, is based on Xen, X and Linux, and is in a basic, alpha stage right now. Qubes relies on virtualization to separate applications running on the OS and also places many of the system-level components in sandboxes to prevent them from affecting each other. 'Qubes lets the user define many security domains implemented as lightweight virtual machines (VMs), or 'AppVMs.' E.g. users can have 'personal,' 'work,' 'shopping,' 'bank,' and 'random' AppVMs and can use the applications from within those VMs just like if they were executing on the local machine, but at the same time they are well isolated from each other. Qubes supports secure copy-and-paste and file sharing between the AppVMs, of course.'" Xen's also just reached 4.0; some details below. Dominik Holling writes "With a small announcement on their mailing list, the open source community hypervisor Xen has reached the official release of version 4.0.0 today. The new features are: 'blktap2 (VHD support, snapshot discs, ...), Remus live checkpointing and fault tolerance, page sharing and page-to-disc for HVM guests, Transcendent memory (http://oss.oracle.com/projects/tmem/).' A complete list of all changes can be found on the Xen wiki and the source can be found on the official website and the Xen Mercurial repositories."

Comments

Virtualization doesn't work vs. file macrovirus

[rsborg]

A document that's infected would still need to be opened, and thus presents a vector that needs to be scanned against. Given the recent PDF exploit issues, I think this is still an large attack profile... still necessitating virus scanners (and app firewalls).

Still, this is still a great advancement... will be interesting to see what performance impact this has.

Re:Virtualization doesn't work vs. file macrovirus

[sopssa]

Sure, but nothing works against every threat. You will never discover a single perfect defense. It doesn't mean its useless to harden the single parts, like in this case OS components to keep rootkits away.

It's dead easy to make a rootkit for the existing operating systems. In Windows you need to hook the system API's. In Linux it's even easier - just replace the system executables. You even have a source code for them, making it really easy to add a simple code that checks if file/process/etc has certain text like "~abc~" and then just ignore that file.

Re:Virtualization doesn't work vs. file macrovirus

[0ptix]

I guess the idea is to run adobe PDF in it's own VM that has minimal permissions. Then when it is infected the virus can't access anything the VM isn't allowd to. (grsec let's you do something like that with the ACLs, roles and users.) For example if you do updates manually then you can restrict the VM of adobe Reader to not have net access. so the virus couldn't contact the outside world either. it's all a question of how much you're willing to compartmentalize your system. the more hassel you are willing to deal with the more secure you can get it (up to a point). This also addresses another comment in this discussion that claims that shoddy coding is not addressed by this fix. the idea of this and similar OSs is to limit the damage after said shoddy coding has been exploited. Not to fix the actual exploitation of that coding.

What i don't get is how this systems is really different from the ACL system of other secure OSs such as grsec... i mean on a high level it seems to be about the same thing. each is a different solution to the same problem of how to compartmentalize your system. in this light what advantage does the new VM based system have over grsec? compartmentalization at a lower level maybe? i.e. even internal to the kernel etc. I don't know enough about how grsec is implemented to know if that is really a difference...

Hardware sandboxing

[EdZ]

With the proliferation of multi-core CPUs and GPU clustering, I wonder how long until VMs simply become entirely separate physical systems sitting on your motherboard.

Sandboxes and Jails

[bhima]

I'd like to read a serious comparison between this and jails in FreeBSD and sandboxes in Mac OS.

I think a lot of these ideas have been around for a very long time but they are such a pain in the ass, very few people actually use them.

Singularity

[organgtool]

This approach seems similar to the one taken by Microsoft in their Singularity OS. I wonder if the issue of context switching will become an issue and if it does, how will it be addressed.

Hardly a victory...

[Jahava]

Let me begin by saying that this sounds like a truly interesting approach to security. Virtualization technology defines very clear hardware-enforced boundaries between software domains. In the standard case, those domains contain different operating systems, each of which are provided privilege level-based sub-domains. In this particular case, each domain is dedicated to running sets of user-space applications, and the hardware boundary is used for userspace isolation, as opposed to virtual machine OS isolation.

So my "home" domain is infected, but my intellectual property is in my "work" domain. The virtualization boundary means that a virus can get Ring 0 access and still not be able to touch those IP files. Hurray ... except wait. There must be an interface between the "home" domain and the hypervisor, else things like copy-and-paste and hardware resource arbitration can't work. Here's what some infection paths would look like:

• Standard XP Install: (Firefox)
• Standard Vista / Linux Install: Firefox -> (Kernel)
• Qubes Install: Firefox -> Home Kernel -> (Hypervisor)

Maybe the paths can be locked down better, but a vulnerability is a vulnerability. It's clearly harder for a virus to get full control, but that's just throwing another obstacle in the way. If one is bad, and two is better, maybe three is even better, but nothing's perfect. Why is the domain-to-hypervisor path considered any more secure than the userspace-to-kernel path? If it's not, you're just adding more complexity, which could mean more potential for vulnerabilities! If you're locking down privilege boundaries, kernels like FreeBSD (jails) and even userspace execution environments like Java (JVM) have been working on that for years.

It's cool, but I doubt it will be game-changing.