According to Joanna Rutkowska, developer of Qubes: "Unlike Qubes OS, Subgraph doesn't (cannot) isolate networking and USB stacks, or other devices and drivers."[1]
[1] https://secure-os.org/pipermail/desktops/2015-October/000002...
On Qubes OS the networking VM runs a standard Linux kernel with no special security hardening at all apart from the simple fact that it runs in a separate Xen VM. If an attacker is able to compromise NetVM, they may not have direct access to user data, but they have dangerous access to perform further attacks:
- Attacks against hypervisor to break isolation
- Side channel attacks against other Qubes VMs to steal cryptographic keys
- Interception and tampering with networking traffic
- Attacks against any internal network this Qubes OS computer connects to.
Subgraph OS hardens the Linux kernel with grsecurity, which includes many defenses against exploitation which have historically prevented local exploitation of most security vulnerabilities against the kernel. Exploiting kernel vulnerabilities locally is so much easier, probably never less than an order of magnitude easier. It's so rare to reliably exploit kernel vulnerabilities remotely even against an unhardened kernel that teams present papers at top security conferences about a single exploit:
https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whit...
I know it's contentious to say so, but I don't believe that anybody will ever remotely exploit a kernel vulnerability against a grsecurity hardened Linux kernel, especially since RAP was introduced:
https://grsecurity.net/rap_announce.php
The threat of remotely attacking the Linux kernel through the networking or USB stack was always low in my opinion, but as the threat approaches zero it raises some questions about how justifiable the system VMs are in Qubes OS considering the system complexity and usability impairment they introduce.
I still think Subgraph looks promising and I look forward to your future work.
I wasn't talking about AppVMs at all, but you can of course persistently backdoor Qubes AppVMs in numerous ways by writing to the user home directory. In Subgraph OS we design our application sandboxes to prevent exactly this.
Could you also answer my question about SubgraphOS main use case and threat model?
Is it mainly for anonymous and pseudonymous usage?
If it is designed mainly for everyday use (including non-anonymous use cases like banking, social media, personal/work email, etc.) as it seems to me I don't quite understand the design choice to enforce all traffic via Tor by default. That seems unnecessary as anonymity is not needed and even dangerous.