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."

Won't work

[jmorris42]

This idea is an example of failing to understand the problem.

The problem with security comes from several primary sources:

1. Complexity. Too many layers with poorly understood security implications. This lady might actually understand the monster she spawned but no admin trying to implement it will understand all of the corner cases. See SELinux.

2. Shoddy coding. So this gets tossed over the wall and will (assuming it is to matter) be completed by people who don't really understand it. Unless this one proves an exception it won't ever get a proper top to bottom security audit of the codebase. So it will have all the bugs in Linux, Xen and the hardware bugs in the virtualization layer and then it will add a whole new set of bugs to exploit.

And this one adds the fact it doesn't even try to secure the apps, it tries to stop misbehaving apps (like SELinux) from accessing things it shouldn't If history shows anything, giving an attacker any access to run code locally gives them all they need to leverage it into root eventually.

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: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.

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.

Re:Hardly a victory...

[Anonymous Coward]

The hypervisor is simpler and therefore easier to audit for issues (or even prove correct).

Re:Virtualization doesn't work vs. file macrovirus

[Fred_A]

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

Current machines (with the possible exception of so called "netbooks") are so insanely fast that the performance impact of a virtualised environment doesn't matter much save for a few very specific applications : games, graphic processing, etc. Not what typical users require. And there are ways to lower the impact when running a high requirement application. It will require a bit more RAM (if even that), but current machines are certainly adequate CPU-wise.

This is IMO one potential direction that OS architectures may have to follow in order to become more resilient in the face of a growing number of threats. I think it would be much more manageable for the average user than something like SELinux. The old permission system isn't in itself sufficient because users cannot be trusted and may "voluntarily" allow malicious applications. So sandboxing everything is reasonable.