I think it is time to make some necessary corrections to our threat model. As shaped by Joanna’s vision, Qubes is entirely focused on certain aspects on breach prevention, lacking any “plan B” (and speaking on prevention, even AppArmor for Whonix and gui-authorized sudo are not in the default configuration yet, and SELinux is mostly untested, because it was decided at once that PVM isolation is panacea). I would say, we are not really prepared for a situation when someone develops a working exploit chain targeting Qubes specifically.
At the moment I find it quite improbable for purely economic reasons. Even if there exists a high value target that uses Qubes extensively and a state level adversary is after them, most likely there would be a cheaper way to find an OPSEC failure, or iPhone used for messaging, etc etc. – to avoid custom research that has little long-term value for an attacker because it cannot be reused on other targets of interest. But it certainly can happen and then what?
We have somewhat-locally-significant “tinfoil hat community” that is , despite being highly concerned of prevention and totally unaware of detection methods and post-compromise routines – once a year or sometime more often we see someone going full mental because of some hardware glitch that triggered a paranoid breakdown.
I strongly suggest that we
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”)
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
easier “self-forensics” and tools to perform cryptographic integrity verification and collect artifacts when we are in doubt
Well, I would not call the defaults really secure. There is no USB qube until you explicitly enable it, there is passwordless root everywhere, there is no AppArmor/SELinux, and I am pretty sure there are other things But the lack of proper security monitoring is my biggest concern so far.
WTF?! Have you lost your mind?!
In Qubes VMs there is no point in isolating the root account from
the user account. This is because all the user data is already
accessible from the user account, so there is no direct benefit for
the attacker if she could escalate to root (there is even no benefit
in trying to install some persistent rootkits, as the VM’s root
filesystem modifications are lost upon each start of a VM).
One might argue that some hypothetical attacks against the
hypervisor or the few daemons/backends in Dom0 (so VM escape
attacks) most likely would require root access in the VM to trigger
the attack.
That’s true, but mere existence of such a bug in the hypervisor or
Dom0 that could be exploited by a malicious VM, no matter whether
requiring user, root, or even kernel access in the VM, would be
FATAL. In such situation (if there was such a bug in Xen) there
really is no comforting that: “oh, but the mitigating factor was
that the attacker needed root in VM!” We’re not M$, and we’re not
gonna BS our users that there are mitigating factors in that case,
and for sure, root/user isolation is not a mitigating factor.
Because, really, if somebody could find and exploit a bug in the Xen
hypervisor – as of 2016, there have been only three publicly disclosed
exploitable bugs in the Xen hypervisor from a VM – then it would be
highly unlikely if that person couldn’t also found a user-to-root
escalation in VM (which as we know from history of UNIX/Linux
happens all the time).
At the same time allowing for easy user-to-root escalation in a VM
is simply convenient for users, especially for update installation.
Currently this still doesn’t work as expected, because some idotic
piece of software called PolKit uses own set of policies. We’re
planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
simple experiment: start ‘xinput test’ in one xterm, running as
user, then open some app that uses PolKit and asks for root
password, e.g. gpk-update-viewer – observe how all the keystrokes
with root password you enter into the “secure” PolKit dialog box can
be seen by the xinput program…)
Of course I have seen that! And strongly disagree. Having “instant root” increases the vm-to-hypervisor attack surface by an order of magnitude. Well, LPEs are commodity, but why make the attacker’s task easier? I think this discussion did already have place several times, and now we have “dom0-assisted” sudo. Xen has amazing security posture, but I’d better not rely on past performance to the highest extent. Things happen. We need to be prepared, that was the point of my rant.
Also, Xen is somewhat “less popular” hypervisor, thus “private” bugs can stay there longer without being exposed if they are known to an adversary. I would also suggest to crowdfund a security audit once a few years.
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 way.
It is. But I just provided a list of things that do not impair the user experience and can be safely applied as default. Speaking on defaults, we need more typical user scenarios (how to properly set up printing? scanning? file sync to cloud storages? etc)
From a usability/admin overhead perspective, Qubes is somewhat like 90’s Linux. Yes you can do almost anything, but there are way too much caveats and it takes expert understanding to do most of trivial things. We need to address this as well.
Linux, not Qubes Well, I probably will. But it takes more than one man effort typically, I have a day job also – so I’d like to share my vision to see if there are others to help
This is not true. USB qube is created by default, unless you have a USB keyboard. In the latter case, it’s not created in order to not block the system from the user.
The inconvenient and somehow embarrassing truth for us – the malware experts – is that there does not exist any reliable method to determine if a given system is not compromised. True, there is a number of conditions that can warn us that the system is compromised, but there is no limit on the number of checks that a system must pass in order to be deemed “clean”.
I am glad that it’s the default, because it greatly simplifies the usage of Qubes. Otherwise I would have to remember tens of (different?) root passwords (or click “OK” tens of times per day). Qubes OS is already hard enough to use without that. I’m also glad that anyone can choose to switch the root password on if they like. Otherwise you are probably right and the attack surface (slightly) increases. Not too much for most people I would say.
“unless you have USB keyboard” means any non-laptop configuration. Also, I feel we all got misdirected in this thread. “Default hardening” is important, but it does not make qualitative difference – detection capabilities do. I will look deeper into the paranoid recovery mode, but it is not the only detection workflow worth following.
This is true. Note that Qubes OS is a reasonably secure OS, not maximally secure OS. New users without much experience will not be able to enjoy and stick with Qubes OS if they are constantly blocked from using the system due to the USB keyboard. (Same with the root password IMHO.)
Do you have a better suggestion how it should be done? By the way, this is the reason why it’s recommended to run Qubes on devices without a USB keyboard.
Anyway, we are back to hardening and I was trying to shift the focus to detection! People here are extremely concerned about ME/PSP as attack vectors, however, I think a scenario when an adversary would be willing to burn a precious ME exploit against Qubes user is even less likely… And you would not notice anything if the detection capabilities are not going to be in place :)))
But the lack of proper security monitoring is my biggest concern so far.