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

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.