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?
