Let your plans be dark and impenetrable as night, and when you move, fall like a thunderbolt.

Arms Race to the Most Secure OS

The Snowden revelations have not only motivated people into building new security-centric tools but also to take a look at the tools we previously considered secure. This holds true for ultra-secure operating systems like TAILS and have created reactionary projects like SubgraphOS and QubesOS. Let’s take a look at the state of these projects as well as their end goals.


TAILS, for years, has been most popular OS for the anonymous community. With official support from the Tor Project (financial and managerial), many regard this as the de facto standard.

The TAILS security model can be considered “classical” in the sense that it attempts to take an existing OS and harden to the n'th degree, add some of the privacy enhancing tools, and make sure there are no compromising flaws.

As stated, we are paying more attention to the secure tools that we use and this has identified some fatal flaws in TAILS. If you look back at the TAILS project, the number of vulnerabilities identified and reported have are much smaller before than after Snowden disclosures.

  • Development: Highly active with multiple paid developers
  • Maturity: First created in
  • Goals: Provide an easy-to-use live environment for temporary work.
  • Roadmap: Continue same model and further harden the OS.
  • Challenges:
    • Minimal support for persistence (besides files). Not designed to be installed but just run once.
    • No mitigations for GCHQ/NSA type low level hardware attacks
    • The focus on supporting all forms of users may affect security

Qubes OS

I’ll start by saying this is the project I’m rooting for. QubesOS starts with the premise that your OS will be exploited. Your browser will exploit you, your storage device will attack your computer, you mail client will try and attack your web browser. To mitigate these risks, they were the first project to successfully implement a compartmentalization model using a hypervisor (as opposed to Linux kernel controls) using XEN.

If that seems too abstract, here’s an example: You want to sell illicit things on the darknet. In Qubes, you build a new WHONIX instance running TBB and all your activities are done in that context.

Technical details aside for a moment, it works similar to how I write about OSPEC: Everything is a separate identity, one identity does not touch the other, when you are done with an identity, burn it. Replace the word “identity” with “virtual object” and you have their security model.

This is accomplished by making several virtual objects. You virtualize your firewall, you virtualize your USB controller, you virtualize the browser you’re using for Project A, and separately, you virtualize the browser you’re using for Project B. From here, QubesOS helps facilitate communications between those objects if necessary.

QubesOS offers some features that no other system currently offers. The big one for me is virtualization for USB controller. So no only are you creating virtual machines, you’re creating virtual controllers. If someone malicious is plugged into your system, even in the case of an [0-day exploiting the firmware of your USB controller], the rest of your system is not compromised.

The other major feature that we know is in the GCHQ playbook is protection from WiFi driver exploits. We’ve heard of this exploit being used in the while but have yet to have a real mitigation from it. With QubesOS, your wireless card is its own virtual object that contains the exploit into its own virtual machine.

There is a lot more to talk about with QubesOS but it does seem the one to watch going forward.

  • Development: Active but a small group.
  • Maturity: v3.1 released is functional but not perfect.
  • Roadmap: Investing time in rebuilding the UI is a priority.
  • Challenges:
    • Hardware support is difficult to predict. They have an approved list but you can’t assume it will work on all systems.
    • Performance is relatively poor to the other systems and Qubes consumes a lot of memory for each of the virtual machines.


SubgraphOS is in the same category as Qubes where it is focusing its efforts to leverage containerization into the system to compartmentalize application. Then an abstraction layer is placed on top to provide communication between said objects.

The main difference between QubesOS and SubgraphOS is that it uses Linux containers as opposed to XEN objects.

The problem thus far is that only a small group of people have seen SubgraphOS working. I’m also concerned about the development of SubgraphOS by the company, Subgraph. We know that Subgraph is a “security” company that aims to provide services and products to its clients. The other two projects discussed here have been community projects and money is not the primary goal. The owner of the company comes from the secure kernel world where he was a mod of one of the most popular and dramatic bug hunting mailing lists.

SubgraphOS had the problem of being announced way too soon. They showed off the now famous SubgraphOS images that caught everyone’s eye before there was anything to actually look at.

I come from the perspective of seeing tons of projects die in the past. The ones that I’ve seen stick through are not usually (ever?) the ones released for free by a money making company.

  • Development: Probably active? Not open to the public.
  • Maturity: Immature, pre-alpha releases
  • Roadmap: Hopefully release a beta to the public soon.
  • Challenges:
    • Money may affect the development of the product.
    • Closed development may deter acceptance of even a finished product.