More practical security for Qubes (and more realistic threat model)

[ppc]

@arkenoi

I strongly suggest that we

1. take defence in depth seriously, there is no need to make attacker’s job more simple, hardening VMs as much as possible while keeping stuff usability-friendly (and write down best practices for everything possible, like, “how to use Dropbox properly with Qubes”, and the answer would be something other than “don’t use Dropbox”)
2. start thinking on heuristics that would help us to keep track of template-based VMs abnormal behaviour, possible backdoors/persistence mechanisms, xen instrumentation for VM introspection, host IDS, integrity checks, health checks (osquery, log processing, “one machine SIEM”, whatever, everything that “grown up” security solutions have for decades
3. easier “self-forensics” and tools to perform cryptographic integrity verification and collect artifacts when we are in doubt

Easy hardening for beginners

Qubes aims to ship with secure defaults, so no general hardening should be necessary (unlike an operating system that was not designed primarily with security in mind). Anything not done by default is probably something that depends on the user’s unique situation (use case, threat model, etc.). In other words, if there’s something that all users should do as soon as they install Qubes OS in order to harden the system, then we (the project) should simply make that the default and ship Qubes that …