Hacker News new | past | comments | ask | show | jobs | submit login
Qubes: an open source OS with strong security for desktop computing (qubes-os.org)
40 points by evangineer on June 11, 2011 | hide | past | web | favorite | 16 comments



This assumes that you can't break out of the VM, and that you can't gather information across the VM boundary. From http://news.ycombinator.com/item?id=2573618:

> ... [C]onsider e.g. http://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf - cross-VM attacks are real, and extremely scary.


When I saw the diagram showing the way Joanna partitions her computing on her blog in March, I thought I was looking at something a schizophrenic would have drawn.

I think this line of research is interesting though, even if I don't foresee ever using it.


KDE, a good choice.

I see they've utilized KWin decorators to display green or red windows, nice idea.


aren't the specs a little too much for an os focusing on security?

Minimum:

4GB of RAM

64-bit Intel or AMD processor (x86_64 aka x64 aka AMD64) Intel GPU strongly preferred (if you have Nvidia GPU, prepare for some troubleshooting; we haven't tested ATI hardware)

10GB of disk (Note that it is possible to install Qubes on an external USB disk, so that you can try it without sacrificing your current system. Mind, however, that USB disks are usually SLOW!)


No, what it does is put everything in different Xen virtualised machines. That is why it needs those specs. It isn't meant to be used as a general purpose OS, it is meant to be used by the paranoid to be able to partition their daily dealings while still using the same physical machine.


I agree - it sounds like a performance nightmare across the board, even with those aggressive specs.

Wonder how it handles OpenGL applications and games.


It is definitely not meant to be used for gaming. The whole idea is to put everything in a Xen virtualised environment so that you can run untrusted applications or applications with untrusted input in different security levels.


Yes, I realize that. The practical concern is that people like to play video games, and if your high-security desktop OS doesn't let them, it will be discarded.


Qubes is not a desktop OS for the masses, it's a niche operating system for professionals who need a high security environment. I would doubt it would be discarded based on lack of game compatibility since anyone who has that level of security knowledge is certainly going to be able to dual boot into whatever more game-friendly OS they need.


That's the thing, though: I am skeptical that your "professional who needs a high security environment" is going to be satisfied by this. It's turtles all the way down--while I know Joanna herself was one of the folks behind the Bluepill attack, why trust Qubes to not be vulnerable to its own version of the attack? (This is obviously an oversimplification and executing such a task is nontrivial--but breaking out of a VM was thought to be a lot harder than Bluepill made it, too.)

The closest thing to an answer to that, as far as I can tell, is multiple computers. Assuming Qubes works as advertised, however, it seems as if it doesn't really scratch the bigger itch--the technology seems cool (I haven't dug deeply into it), but does it address the social/usability problem of security, even for these professionals who need that high security environment?

From reading about this, it seems as if you could have stopped at "it's a niche operating system," because to my mind it seems like professionals who need a high security environment will just have multiple computers. If a segmented system like Qubes is not going to run the stuff that your hypothetical professional will want to run (games just being an example, and one that seems to have been misleading), then why would it be preferable to just rolling multiple computers? (Cost, which is the only advantage I can think of, doesn't strike me as a significant factor to folks who are actually doing things that necessitate this sort of security.)


There has been a lot of work out there on how to use a "separation kernel" (basically, a hypervisor with proven/provable levels of isolation between guests), plus stuff like Intel's VT-d, VT-x, etc., to provide real isolation between guests. (also, really useful for RTOS and embedded systems)

If you've ever worked in a high security computing environment, you've had N workstations on your desk, where N is often approaching 5 -- NIPR, SIPR, JWICS, various task-specific machines, etc. These environments aren't just nice air conditioned purpose-built offices in the US; they're tents in Afghanistan, on aircraft and cramped warships, etc.

Sometimes people use KVM switches, but even then, you need separate hosts, and it's usually best to use multiple monitors and keyboards anyway.

Invisible Things was has been testing the limits of current hypervisors, and there's room for them to both work on what is possible once a real separation kernel exists (now) in prototype form, and to continue to refine hypervisors and develop a real separation kernel.

I'm still kind of amazed that these 2-4 people in Poland are probably the world's foremost experts on hypervisor security.



I'm not claiming they're going to be satisfied by this or that the technology even addresses any security problems. My point was that gaming in not a necessary feature or a selling point of Qubes and that the demographic who would a) know what this is and b) have a use for it in their business/research, is not going to use it based on it's ability to run Quake.


IMO, the real alternative to Qubes is running some kind of trusted windowing system/kvm switch/x display equivalent that doesn't suck, and then connecting to distinct remote hosts through some kind of security proxy, each running system-high security.

That protects you from hypervisor and hardware attacks. The only thing you need to trust is that none of the guests can induce the windowing system to incorrectly direct output, and that the windowing system can enforce access control (mandatory or discretionary) to the various guests.

The basic/extant version of this is putting a bunch of discrete devices in different security domains on serial ports, and then having a trusted console server to intermediate everything. A console server is vastly simpler than a full graphic windowing system like X Windows, much easier to audit, and more secure.


Kinda hoping it's late where you are, like it is here, because otherwise your comment is pretty silly. Absolutely no one that finds this interesting is going to give a crap about playing games on it - just like nobody cares about gaming on the BSDs, or Solaris, or even Linux.





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: