Theo de Raadt, 2007
Given that amazon uses xen in the EC2 platform(as many others), we're not only talking only about "worldwide collection of software engineers " but also of some serious commercial interests in it's security.
And XEN might not be the end point of that approach. There has been some research on formally verified hypervisors.While it's not 100% foolproof since you still have to depend on hardware security, which is a unknown(does intel cooperate with NSA?), that could give great assurances for system security.
Intel and NSA are not the problem. The real problem are hackers who want to steal our bank accounts, or the commercial providers who want to have all our private data to sell it secretely. For such daily problems I consider Qubes a very good protection. It's very nice to be able to do banking or web browsing in isolated VMs. It's also nice to have insecure OS like Windows run almost securely in a VM.
its not small
EDIT: Here is some documentation that describes the security stance of the Qubes OS project. As you will see, being security-bug-free is not a goal, and in fact, the guiding principle is that all code has security bugs, hence everything is isolated to prevent escalation. http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf http://qubes-os.org/trac/wiki/SecurityCriticalCode
Disabling virtualization capabilities in the bios is a semi-common recommendation for securing a computer... Still, this OS is a darn sight better than nothing and it'll certainly protect against most things. However, touting it as perfect is misleading.
If an attacker has to exploit the browser to get access as an unprivileged user, then find a local exploit to get root on the VM, then circumvent SELinux on the VM, then load a kernel module on the VM that exploits the hypervisor to get DOM0, then the attacker needs to burn a lot more 0-days and considerably increase their chances of getting caught compared to just exploiting the browser and going straight to accessing the information they want.
Unfortunately, some types of attacks might bypass multiple layers in one hit (e.g. exploit graphics driver on X server VM through WebGL, install keylogger on X server).
Can you expound on that comment?
Yes, the only thing the attacker can do is compromise all of your chat conversations and impersonate you on an ongoing basis. Maybe you keep a separate browser VM for sensitive work: good, but only secure as long as you never ever accidentally visit a site you don't completely trust, such as any HTTP site.
Don't get me wrong, I think Qubes is really cool, but our ultimate goal, collectively, should be an OS where the entire stack, except possibly a few lowest level components (but not including things like filesystems and network drivers), is written in a higher level language than C/C++ and guaranteed free of memory corruption vulnerabilities in the first place. While non-memory corruption vulnerabilities exist, they're generally drastically easier to reason about and prevent, while C vulnerabilities can be anywhere, with exploit mitigations that make most attacks only harder, not impossible.
In the meantime, I guess you could always browse using Chromium with ASan enabled :)
* I love high level languages, but is there even a toy OS that provides a decent amount of functionality with tolerable performance without cheating? * There is no silver bullet to anything, let alone security. Automatic bounds checks only solve that one problem.
For instance, most would consider this an order of some of the vulnerabilities that potentially exist in increasing severity. And note that the first one is what Heartbleed is qualified as.
* Buffer overrun on read * Buffer overrun on write * Arbitrary code execution
It should be noted that the OS's VM'ing is based on the Xen bar-metal VM kernel which is pretty well researched, small, and elegant.
I really hope these approaches like Qubes take off and that things get optimized for this type of workload. I'm not sure why Microsoft has ignored lightweight virtualization, both on client and server.
(note: genuinely curious. I've gone down this route before myself before realizing there was simply too much overlap between my "sensitive" and "normal" work. I still employ similar configurations but for protection against data corruption, ease of system administration, and R&D purposes only.)
It's not perfect, but at least when a client wants me to run some damn .exe to join their oh-so-great screen-sharing platform, my home environment isn't messed up. And I can run random games or utilities and quickly revert to a snapshot.
The most sensitive keys stay in the host partition.
edit: I remember there were similar concepts a decade or so ago. where you had your "green" desktop for intranet or whatever and then a seperate "red" desktop which you could switch to and go to the evil internet. hint: no benefit gained
But it is dangerous to educate non-technical people that this VM-based OS gives you absolute guarantees of security.
And please don't start redefining the term "air-gapped" such that it applies to a VM that doesn't have network access. "air" "gapped" is a pretty absolute concept, and does not mean a VM without network on a host that does.
What I'd really like to work on is Compartment Mode Workstation with physically distinct hardware.
Essentially, a "windowing KVM" frontend to a bunch of physically separated processor/memory subsystems, connected via well-defined networking interfaces. Essentially X Windows, but actually secure. This is sort of how desktop virtualization (VDI) works today, but with a separate instance per application.
It would be reasonably affordable.
Upper limits on the number of processes you could run would be dictated by how many modules you plug in, you could make a backplane like model where you daisychain multiple backplanes for more processes.
[1]: https://groups.google.com/forum/#!topic/qubes-devel/uLDYGdKk...
If you are referring to Mac OSX and its integrations with App Stores and social media systems, note that it is entirely optional (I don't use any of the social media guff bundled into the OS).
Unless you are referring to something else and think that buying a piece of hardware somehow means you don't care about privacy, regardless of which software you are running on that piece of hardware?
I don't think the piece of hardware is relevant?
If security and privacy are of some importance to you then using a OS with closed source essentials due to ease of use or development environment only increases the number of years until a strong privacy easy to use OSS system gets rolled out more widely. Your actions have broader impact than just your priorities.
Finally, there is more than just the software. Getting closer to the metal you have to contemplate bootloaders trust and verifiability.
The people working on this are sharp, for sure.
But I will never think of VM's as a path to "security".
Xen is useful for a variety of purposes (including resiliency, which can help if you are hacked), but I'll never rely on it for "security".
Curious what bootloader they are using for the Xen kernels.
The bootloader I use can boot Xen kernels; no need for GRUB2. Is the Qube boot process described somewhere?
"it is possible to move all the drivers and driver backends out of Dom0. The same is true for moving the IO Device Emulator (ioemu) out of Dom0."
From where I sit, vulnerabilities in virtualization have seen less public scrutiny than the Chrome sandbox. Eg none of the hypervisor vendors have a bug bounty program, which would be at least some kind of signal.
Of course it's not perfect, but xen has a pretty good track record. And a significant chunk of the flaws that have been found xen were found by the qubes devs.
Hell, Cryptolocker shows up that fundamentally the whole thing is solving the wrong problem in the first place for ordinary users, which is who cares if the OS survives if your data doesn't?
1. By default, there is no need for an attacker to find a local exploit to get root--the user account has unrestricted password-less sudo authorization. This is one of the things I disagree with the developers about.
2. SELinux is disabled in AppVMs by default.
3. The GUI virtualization architecture takes this into account, and uses Xen shared memory to blindly copy a framebuffer prepared by the domU X server. Exploiting the dom0 X server should be very difficult.
Also, one main attractive feature of Qubes is the networking architecture: so long as iptables is not compromised by an attack, and there is no Xen sandbox breakout, it's fairly easy to set very restrictive or specific firewall and routing rules which will thwart many zero-day threats.
Further, VMs externally look no different than any other Fedora 18/20 installation, so even if an attacker had a Xen sandbox exploit, they would have to have specific knowledge that you run Qubes (e.g. you posted to Hacker News saying so ;)) in order to own your system, which is security 'by obscurity' but is still useful.
Qubes is more of a powerful security-enabling tool than a 'secure by default' distribution. Non-technical people (e.g. human rights lawyers, national security reporters) should probably use Tails unless they have a high degree of technical sophistication. It's very easy to shoot yourself in the foot.
I've been using qubes for a little while myself. I agree that it should be harder to go from domU user to domU root. However I think having to manage passwords for every AppVM also negates a lot of the benefits of the template setup in qubes (I currently have about 30 AppVMs).
My ideal solution to this problem, which I might implement at some point, would be to implement a PAM module for domU that asks dom0 whether escalation to root is okay. That way, dom0 can prompt the user whether to allow it or not, and no per-AppVM passwords have to be remembered.
I understand it reasonably well and am hesitant to switch.
I have tried others and have not been impressed.
I am a connoiseur of bootloaders I guess.
It's an important program, maybe the most important one.
Based on my limited knowledge of other computer users, I believe we all have what we consider a "trusted" program that does some task for us over and over again. We come to rely on it and appreciate it (for our own idiosyncratic reasons). We are hesitant to switch to something else.
For me, that program is my bootloader.