Researcher Releases ‘Qubes’ Hardened OS

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.

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 implements Security by Isolation approach. To do this, Qubes utilizes virtualization technology, to be able to isolate various programs from each other, and even sandbox many system-level components, like networking or storage subsystem, so that their compromise don’t affect the integrity of the rest of the system.

Qubes lets the user define many security domains implemented as lightweight Virtual Machines (VMs), or “AppVMs”. E.g. user 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.

The concepts of isolation and sandboxing have been around for decades, and are used in a number of applications, including hardened operating systems and some security products. And many security experts say that sandboxing is one of the more effective ways of preventing malicious code from affecting entire systems, rather than just one vulnerable application.

In a guest column in January on Threatpost, security researcher Dino Dai Zovi said that he expected more and more vendors to implement sandboxing and isolation in the coming year.

“The desktop analogue to the network firewall is the privilege separated
and sandboxed application.  These mechanisms finally move the
bull (untrusted data) from the china shop (your data) to the outside
where it belongs (a sandbox).  While it doesn’t quite reduce the attack
surface, it significantly raises the bar for an attacker through
defense-in-depth.  If an attacker is able to exploit a vulnerability and
execute code, they must then exploit another vulnerability in the
sandboxing mechanism in order to break free and even read the user’s
data,” he wrote.

Rutkowska said that she plans to release the full version of Qubes by the end of 2010, and that she may create some commercial extensions to the OS in the future.

Suggested articles

Research Finds Crystal Material For Chip Security

Researchers at Florida State University have discovered crystals that could lead to super security chips. The security chips could store encrypted data written two different ways — electrically and magnetically — making extraction of the data more complex and so more difficult for attackers to decrypt. Read the full article. [NetworkWorld]

Discussion

  • Anonymous on

    Xerobank has been working on a Virtualized Browser for a few months now.  This also sounds very exciting!  Looking forward to it!

     

  • Anonymous on

    Cool this chick is both smart and sexy. Cant wait to see how this OS develops!

  • Anonymous on

    This is an interesting development, but by no means a revolution. People interesting themselves for this kind of thing would do well indeed to be mindful of all the things available, not just the newest one. Because this is brand new code and the author is one of the few that understand the lower levels enough to do a proper audit. Meaning that finding able outside parties, to do peer-review and squash potentially devastating bugs that may have slipped in, will be hard indeed. Yet she apparently didn't see fit to build on a code base that has seen more than a decade of focused security reviews. I'm hinting at OpenBSD here. Instead we're looking at mostly new code. In that sense this is a bit of a reinvention. This likely has its roots in most of the so-called developed world insisting on using a piece of swiss cheese with entire mouse colonies within as a foundation for their computing endeavours. The rather predictable result is that at least some ``security researchers'' are stuck ``researching' that piece of vermin riddled holey cheese such that they seem to lose sight or were entirely unaware in the first place of alternatives that have managed to not attrract so many vermin by better design. In that way this xen based OS is an interesting excercise, but also a healthy dose of incredible overkill. Entirely understandable seeing where ``we'' come from, but like everything else it's no silver bullet. So, let's not forget what other techniques are already available, and often have been for a long time and are quite mature. Like chroots, jails, MAC frameworks, zones, containers, LPARs, what-have-you. Or even just all those systems unlike the monopolist monoculture that provide reasonable user separation instead of badly faking it (and failing) and aren't promiscuous by non-virtue of lacking coherent design.
  • ThoSil on

    So what's the next step? If your running app is in a container, why not move/migrate it to an other running os? Take a snapshot and roll back if needed, pause an app so it don't use cpu anymore while it's not needed... what you can do actually with a VM is what you can expect to have for a virtualized application. Maybe that is the future of computing?

  • Alhazred on

    OK, but sandboxing doesn't solve as many things as people seem to think it does. Remember, an application on any modern OS is already 'sandboxed', it has its own address space in virtual memory, lives outside of ring 0, etc. This is NO different from the situation encountered by a virtualized OS. Perhaps less code may be running in system space but then again maybe not. 2 issues crop up. 1) Any application, sandboxed into a VM or not, requires access to data in order to function. That access is going to be, logically must be, accessed via some sort of code running in the VM. Once your sandbox is owned by the bad guy, he DOES have access to that whatever data the app could access. Again this is identical to the situation in any normal OS. OSes have had the ability to put security constraints on processes since forever, which can and should reduce the danger of an exploit, but as we have witnessed in the last 20 years this is never enough. I could use SELinux to nail down my browser right now, except exactly who is smart enough to actually know how to do that for every application and do it in a way that suites MY use cases? 2) Inevitably as you have more VMs accessing more stuff you start to see the walls between them come down. Just for the sake of efficiency things like file systems and devices end up living mostly at the hypervisor. Pretty soon you're back where you started from. Already you see COW/block deduplication being implemented between VMs, it will go further. Whatever value these VMs have beyond that of an app in virtual memory evaporates. At a theoretical level at least VMs really aren't better than what we have now. Practically speaking probably yes, but I wonder if the advantage will last long.
  • Nick P on

    This is actually a waste of time. Everyone keeps doing redundant work. Green Hills INTEGRITY Padded Cell and LynuxWorks LynxSecure solved this problem commercially, with OKL4/seL4, Nizza Architecture, Perseus Architecture, and Nova microhypervisor doing it open source and free/semi-free. The L4 and commercial groups have a well-validated microkernel, needed base services/drivers, a POSIX/Linux/other VM for legacy apps, and frameworks to integrate isolated apps with regular apps. We could build a trusted workstation, router, VPN, etc. if we started there. And now, instead of progress in one of these directions, we have (sighs) *another* OS acting as a hypervisor/MILS/security kernel. We don't need it. We already have a good start with the other systems. Now, we need to work below (trusted hardware/firmware) and above (drivers/libraries/coreservices).

    I'd be overjoyed to see the lovely Joanna use her extensive hardware experience to actually create trustworthy hardware. Particularly, an open-source processor and firmware that's i686 compatible with MMX, SSE, Intel VT, IOMMU, and trusted boot capabilities that was produced using the strongest defect reduction techniques & verified to have no errors in security-relevant functionality. Examples moving in that direction are AAMP7 and VAMP. With this, we can use existing assured kernels, hypervisors, frameworks, etc. to build usable, secure systems. We need the hardware gurus like Joanna to do their part first, though, because we will otherwise be building stone fortresses on muddy foundations.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.