Researcher Releases Hardened OS "Qubes"; Xen Hits 4.0 129
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."
Remus (Score:3, Informative)
The Remus stuff in Xen is very cool. A couple of days ago there were some posts about HP's NonStop stuff as an example of something you could do with Itanium but not with commodity x86 crap. Remus means that you can. It builds on top of the live migration in Xen to keep two virtual machines exactly in sync.
Computers are deterministic, so in theory you ought to be able to just start two VMs at the same time, give them the same input, and then see no difference between their state later on. It turns out that there are a few issues with this. The most obvious is ensuring that they really do get the same input. This means that they must handle the same interrupts, get the same packets from the network, and so on. Anything that is used as a source of entropy (e.g. the CPU's time stamp counter, jitter on interrupts, and so on) must be mirrored between the two VMs exactly. This was already possible with Marathon Technology's proprietary hypervisor on x86, but is now possible with Xen.
As with the live migration, you can kill one of the VMs (and the physical machine it's running on) and not even drop network connections. This leads to some very shiny demos.
Oh, and I should probably end this post with a gratuitous plug for my Xen internals book [amazon.co.uk]
Re:Virtualization doesn't work vs. file macrovirus (Score:4, Informative)
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:Virtualization doesn't work vs. file macrovirus (Score:2, Informative)
Its pretty easy to make a rootkit for any PC based OS ... the real problem is getting it loaded before the main OS. Contrary to popular belief, even with the advent of hardware virtualization helpers, boot viruses that hid themself away from the main OS are nothing new and have been around probably longer than you've owned your own computer.
The rootkit simply has to be first, after that theres nothing anyone can do.