Working with Qubes OS at the Guardian
theguardian.com
theguardian.com
Qubes is awesome, but it's no substitute for an air gap.
This is the same publication that broke the Snowden story. Their adversary collects hardware backdoors like baseball cards. This is not smart.
I would think twice before making a whistleblower disclosure to an organization that thinks this way.
Possibly mention a specific virtualization system, and then run a honeypot version of the above to try and catch directed attacks at it while actually relying on a totally different system...
It reads, at least to me, as a PoC on them wanting to "standardise" end point creation to talk to them securely; given the introduction points to "you may have come across the ‘Contact the Guardian securely’ banner".
In many cases it's even more secure, especially if you're constantly exchanging untrusted files via USB sticks: https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u...
"Qubes is awesome, but it's no substitute for an air gap." - agreed - for some stories an actually air-gapped machine is essential - if nothing else just because it's very easy when messing round in Qubes manager to add a netvm to the wrong Qube.
However, of the stories we receive coming through SecureDrop system, many don't have the risk profile of something like Snowden - e.g. a local politics story that GCHQ aren't likely to be too fussed about. For these cases, it's helpful to have an environment which is secure, but has a browser available for e.g accessing our CMS or doing research.
What it sounds like is that you are proposing a system that is less secure compared to what is already in place and this is what people are protesting against.
Has journalism has fallen so low that sensitive information is handled with wanton abandon just for the sake of convenience?
Assuming what is said here is true, nobody should be providing sensitive information to The Guardian if for no other reason than to guarantee their own safety.
That is disappointing.
There is also split GPG, to transfer encrypted data to a VM containing Gpg keys.
But the ease of use could also mean that the user turns on and off the networking, bringing an air gapped VM sometimes online.
There is a need for a permanent one way VM.
That is not an air gap.
The hypervisor is software. Software has bugs. I'm sure the NSA has some hypervisor escape zero-days...
I reckon a startup could do it.
Dont know how true it was or is, but I've seen some of these devices now advertised online. I'd provide a link if only Google & Bing would deliver the results, and were also psychologically engaged in warfare on the population.
https://en.wikipedia.org/wiki/Van_Eck_phreaking
https://en.wikipedia.org/wiki/Tempest_(codename)
Though for a second I thought you were going to talk about the mythical TV licensing detector vans :)
I have a bridge to sell.
https://www.csoonline.com/article/561467/xen-hypervisor-face...
You did not even try to confirm if what you said is true.
If you did not know about this previously, then why should I believe someone who boldly asserted that a system was "virtually impossible to break", despite the fact that your average developer would laugh at the idea such a thing exists, and was then trivially proven to have no idea what they were talking about, but has now backpedaled to a different stance after some hasty research?
For that matter, even if I take your statements at face value, why would a design goal have any impact on the security of a system. Those are called goals, you can fail to reach them. You need to present verification and audits that the goals were achieved. Given that you literally can not name a single other piece of software that has achieved the goal of "virtually impossible to break" (except by absence of evidence), you can not just assume such a goal is achieved.
Given that we are talking about press organizations that are regularly attacked by state actors, "virtually impossible" in this context means it needs to be proof against state actors. So please present literally anybody who claims that state actors such as the NSA can not breach a Qubes system, then you can present their evidence. I am certain not even Joanna would make such a ridiculous claim and would shoot down anybody on the development team who tried to make such a claim. There is a reason their tagline is "A Reasonably Secure Operating System", not a "Virtually Impossible to Break Operating System". They know it is not proof against state actors and they have the honesty to say that unlike the snake oil peddlers commonly seen in cybersecurity.
Yes, I knew. In the context of this article, we are talking here about the currently supported Qubes release (4.2), which implemented the new virtualization mechanism. The latter was not broken in your links, or anywhere else after 2006.
It's not a design goal but actually working implementation at present.
> "virtually impossible" in this context means it needs to be proof against state actors
First of all, nothing is 100% proof against state actors, because they can use completely different attack vectors. I just believe that the VM escape attack vector is extremely unlikely in this case, and I rely on the lack of known escapes to make this conclusion, which should have been clear from my comments.
I mean, seriously, find me a single person in the entire world doing offensive cybersecurity research who thinks there is any system in the entire world that can stop any team with a 10 M$ budget. Find me any single person in the entire world doing cybersecurity that would place a open bet that they could stop any team with a 10 M$ payout. I am certain you would be laughed out of the room in the former, and you would see dollar signs in their eyes if you introduced them to the latter. Stop propagating marketing fluff.
That is not to say that Qubes is horribly insecure. It is just not even close to "virtually impossible to break". And, to their credit, they are honest and very clear about this in their messaging and should be applauded for it unlike actual bad actors like Crowdstrike, Microsoft, Apple, Palo Alto Networks, Google, Sentinel One, (basically everybody) etc. who just make up whatever security bullshit to push product. It, however, does no good to make up random hyperbole with no basis in fact for products that are actually being careful to not overpromise. Frankly, it is doing the team at Qubes a disservice because people will hear the nonsense and then get burned and blame Qubes even though they were careful to honestly express the limitations.
But their recommended hardware makes it pretty clear Qubes should preferably be run on open firmware and with ME as broken as reasonably possible (as has already been pointed out in the discussion here).
Also I don't see how it's a low bar. AFAIK there were no known remote exploits of IME.
> You don't need QubesOS to protect from known exploits
Qubes would protect you sensitive files from, e.g., XZ attack. Nothing else would AFAIK.
there's a reason security test of malicious code is done on fully software emulated qemu without kvm anywhere.
The way I read it is that it eliminated the need for an air gap for their needs, not the need of humanity as a whole.
link?
MIT Technology Review -- NSA’s Own Hardware Backdoors May Still Be a “Problem from Hell”
"This month, news reports based on leaked documents said that the NSA itself has used that tactic, working with U.S. companies to insert secret backdoors into chips and other hardware to aid its surveillance efforts. That revelation particularly concerned security experts because Hayden’s assessment is widely held to be true."
I'm not sure if I should be amused or horrified that people in this thread don't seem to understand what an air gapped computer is.
They cite that it removes the need for an air gapped system… They’re not claiming that it is one, just that it meets the requirements for their needs.
Also, since when was the concept of an air gap a one that only the vaunted druids of old could fathom?
1. If you need an air gapped computer, your threat model includes literally any electrical wire connecting to the outside world.
2. If you need an air gapped computer, your threat model includes literally any radio signal.
With this in mind, there is no way in fucking hell that a virtual machine can satisfy your requirements. That virtual machine literally resides on the same fucking wires as the host computer, this is even worse than a wire connecting two computers.
The Guardian is a media outlet, their job description is receiving information from sources securely. Some of that information will be extremely high value, like "the wrong people seeing this will lead to murders" extremely high value. Handling that kind of sensitive information absolutely requires air gapping to minimize your attack surface as much as humanly possible. Note humanly possible, not reasonably possible; reasonable isn't enough.
A properly air gapped computer is going to use as few physical connections to the outside world as possible. It will also be shielded from all radio signals. The only way to access it is a physical human moving from the outside world to secured space in which the air gapped computer resides.
If your threat model can be satisfactorily defended using virtual machines, you never needed air gapping in the first place.
If I need to prevent exfiltration of one logical machine’s data to another, and I’m in physical control of the hardware running both of them, I can:
(a) Try to prevent any electrical, radio, power, acoustic, or other signaling from one to the other, or:
(b) Run both in a fully deterministic mode such that the execution of one has no effect on the execution of the other.
Both have different costs and their security hinges on different sorts of verification, but it’s not at all clear to me that (a) is inherently better than (b).
A threat model that necessitates an air gap is indeed a strange one, I daresay even ridiculous.
To put it frankly, most people simply will never have to consider such a ridiculous threat model. Being suspicious of everything down to literally the copper wire in your power cord is something most people will rightfully consider ridiculous. For most people, a virtual machine will provide more than ample security for their needs, and it's been mentioned already that Qubes itself is great so nobody is discounting the value there.
The problem is we are not talking about normal people. We are talking about highly specific, highly special people handling highly valuable work, dogged by highly powerful hostiles. The very nature of these people and their work is ridiculous, which necessitates considering ridiculous threat models and implementing ridiculous security measures to guard against them.
Where someone needs an air gap, replacing that with Qubes is mind bogglingly stupid because to quote karma_pharmer who put it very poignantly[1]: That is not an air gap.
>If your threat model can be satisfactorily defended using virtual machines, you never needed air gapping in the first place.
There’s a very reasonable threat model in which KVM or Hyper-V or bhyve or Xen is inadequate and an air gap provides stronger protection.
But that’s not my point at all. Many uses of computers need to interact with potentially untrustworthy data, and make uses need to interact with untrustworthy transports that carry trusted data. An air gap is of little value if nothing can cross it. (Yes, some sets of threat models and design criteria allow data diodes.)
If I had a nation-state budget and wanted to get data across a gap, I would look toward a deterministic, formally verified VM. This is quite practical — a very simple, small VM can run an emulator that can emulate x86 or ARM. And I would also consider an air gap. But keep in mind that an air gap does not protect against persistent compromise of the thing on one side, whereas a formally verified VM does.
An air gap means there are physical barriers that are locked down (you are installing physical barriers and locking them down, right?), which means you can inspect anyone and anything trying to traverse it and prohibit anyone and anything that is even remotely suspect.
The fact you are even asking this demonstrates you (by far the most vocal of the "Qubes is enough" crowd here) don't understand air gapping.
In the article, they explain how they made a real, practical step towards a better security. Perfect is the enemy of the good.
I also like this reply: https://news.ycombinator.com/item?id=39952028
EDIT: Maybe these guys aren't experts and don't deserve to receive and handle sensitive information: https://news.ycombinator.com/item?id=39954815
There is no way to guarantee there will be no unauthorized access or movement of data without a hard, physical gap requiring manual, scrutinized traversal. No amount of software or hardware mitigations can suffice.
If Qubes is satisfactory for The Guardian, then they never needed air gapping in the first place. I find that hard to believe given what their job description is, but that is ultimately none of my business (though I won't give them any sensitive information, for the safety of both myself and others).
Meanwhile, if you need air gapping then Qubes by itself absolutely cannot satisfy your security needs. Because a virtual machine is not an air gap.
You absolutely still have not read their comment.
You can rant on about how they should treat their data as as if they’re nuclear launch codes, but they’ve made a deliberate decision to implement a solution that is secure enough for their needs.
If you still disagree, that’s fine, but the fact that you don’t understand the immense burden that a truly air gapped network would have on users and administrators speaks volumes of your own understanding of these types of systems and solutions.
>You can rant on about how they should treat their data as as if they’re nuclear launch codes, but they’ve made a deliberate decision to implement a solution that is secure enough for their needs.
Indeed, I disagree with The Guardian's assessment that virtualization is sufficient to protect their information. It's ultimately none of my business (literally so), though that won't stop me from being appalled at their callousness and I for one certainly won't provide them any information if I'm ever in such a position.
More generally in regards to this thread, I am horrified that so many people genuinely think virtualization can be a replacement for air gapping. Especially in the wake of vulnerabilities like Specter/Meltdown and Rowhammer, among many others.
>the fact that you don’t understand the immense burden
I absolutely understand how much work is required to create and maintain an air gapped environment, and the sheer inconvenience and borderline impracticality using them imposes.
I'm saying that handling sensitive information of this kind warrants all that and cannot be replaced by something easier, though I can sympathize with desires to do so because noone likes hard work.
(You have to physically remove the wifi and bluetooth hardware)
Also, one-way diodes are fine, mostly.
But I agree completely. There's a major lack of awareness.
I'm quite angry that firewalls on phones isn't a thing - and that you have to use a VPN workaround. Why is such a basic feature missing? (Oh wait, I know: advertising revenue, and uh, intentional vulnerability)
there's no pure linux even on the main cpu, let alone in the entire device with separate computers for radio, camera, lowpower mode, etc.
nothing on that SoC is free or open.
btw, misleading everyone by running the blobs in a separate core with the same accesses of the main ones just to brute force certification is even worse than admitting you couldn't get free of the blobs, like the pine phone people correctly did.
> You can use a firewall on GNU/Linux phones though.
And that's true. There are phones, that run GNU/Linux distros, that give you a working software firewall. Pointing at blobs doesn't make it not GNU/Linux on a phone with a firewall. At best it points to a place where a firewall could be undermined, but if that's your standard then (nearly?) everything fails, including actual literal firewall hardware appliances (I'd take Linux nftables on a blobbed network card over Cisco any day).
Correct, and not getting why that is the worse of the options puts you out of the discussion in this thread. sorry.
Could you provide any links or details?
Do you use specialized equipment and processes, e.g. PDF-to-PNG rendering, one-way diodes, and such?
Also, I'm surprised to hear so many stories about crypto theft. Aren't there any airgapped solutions? And why aren't they mainstream?
Safer than swapping around thumbdrives, harder to screw up.
They’re not mainstream because crypto isn’t mainstream outside of the crypto-bro community, mainly because it’s inconvenient for both parties trying to make a sale or purchase.
I’ll tell you what is mainstream though: chip+pin and nfc+bio, which in combination with a ‘good enough‘ key storage and interrogation regime, are a decent balance between convenience and security.