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

[99BottlesOfBeerInMyF]

A document that's infected would still need to be opened, and thus presents a vector that needs to be scanned against.

If the PDF viewer is running in a separate VM container, however, what exactly do you think it's going to accomplish? Read your other PDFs? sure. Delete them even? Okay. But since you probably did not give that VM access to your network it's unlikely to be able to do anything actually beneficial to a malware writer.

...still necessitating virus scanners (and app firewalls).

Well, virus scanners are a bonus, although not a lot of use on Linux given the amount of malware out there. Configuration of VMs takes over a lot of the same task as application level firewalls here, although the overhead tradeoffs of each approach should be looked at.

Re:Virtualization doesn't work vs. file macrovirus

[Jahava]

I think the idea is that you'd run different domains to protect different sets of files. You'd run your tax software in a "tax" domain, and if any PDF software got infected, it wouldn't be able to touch the "tax" domain information.

Versus locked-down operating systems, you have a valid point (and my personal issue with this approach). However, it's not without its advantages. In a standard Linux system, every userspace process has access to around 330 system calls. Each one of these is an interface into the kernel, and a bug in even one of them is enough to take over the kernel. Furthermore, any application that can load kernel modules can potentially dominate the kernel.

In the Qubes system, each domain is protected by a virtualization layer. It does have domainhypervisor interfaces (similar to system calls) to allow I/O, graphics, and the copy-paste subsystem to run, but there are a lot fewer of them. They are oriented around a finite functionality - the aforemented I/O, graphics, etc., while system calls must exist for all userspace functionality. Therefore, as userspace applications get more complex and system calls (per-domain) increase in number and complexity, the domainhypervisor interface will be more or less static. This hopefully leads to them being easier to secure and lock down.

Re:sounds promising

[metamechanical]

And that, ladies and gentlemen, is the TRUE spirit of free software.

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.

Re:Won't work

[Archangel Michael]

1) Any system simple enough that anyone can use it, is either a toaster, or won't be useful in any customized way.

2) Coding doesn't need to be "shoddy" to be a security risk. It just simply needs to fail to realize the edge cases nobody thought of when writing the code. If you make the code complicated enough and run enough checks, it becomes complicated mess that nobody wants to use.

The problem with security is one of optimizing the risk to the amount of protections built into the system. Back in DOS days, I'm sure that DOS was insecure from many many levels, however because it was standalone, the security of "networking" wasn't even considered.

However the #1 security risk with computers isn't "code" or "Programs" or Hackers or whatever; the BIGGEST problem is Social Engineering, of which there is no fix other than "Stupid should hurt".

When a web dialog box can mimic a system dialog box saying "Your Computer is Infected CLICK HERE to fix it", which downloads and installs Antivirus 2010 crapware, the problem isn't Firefox, Windows or anything any programmer can fix. PEBAC, PICNIC and 1D10T errors aren't fixable by programmers.

And if you had to fix these problems you'd realize that Hackers and such are spending more time on social engineering attacks to get their viruses, trojans, and other malware onto computers than traditional methods.

Re:Hardware sandboxing

[kgo]

Then they'd just be M's... ;-)

Interesting but the problem is the end user.

[spacepimp]

The real issue still resides. The end users (PEBKAC). Take my father for example. Sure you have a Qube for banking and Qube for work and a Qube for home use. Now the home use one where he does his "Magic" or whatever he does to infect/taint/destroy any PC I put in front of the man, gets entirely infected Spywared/Malwared/chuncked and muddled. So he can't get to his phishing emails about how to make millions in the internets and by getting the diamonds out of Namibia. He cant do that from the infected Qube. He'll then go up the chain to his private banking Qube to install his makingmillions.exe so it will work again. Long story short.... Some people cannot help themselves but by being victims. I'd give the man Linux but he always finds a reason it's keeping him from being successful... I know by keeping these Qubes sandboxed it will be harder for it to get the taint, but they will find a new way to find my father.