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.
That is disappointing.
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.
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.
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 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.
there's a reason security test of malicious code is done on fully software emulated qemu without kvm anywhere.
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.
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).
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 :)
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."