If I was their security team, I would be fine with them publishing articles about our security set up - as long as it wasn't 100% accurate.
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...
> I would be fine with them publishing articles about our security set up - as long as it wasn't 100% accurate.
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".
Spectre vulnerabilities are a huge problem. Problems in x86_64 never cease to emerge. Qubes Air is probably the most outstanding viable approach to not exactly mitigate CPU and chipset problems but avoid them or leave them moot.
Hey, author of the post here. I've had quite a bit of feedback on the post from some people with a lot more Qubes experience than me - there are definitely some issues with it - e.g. you can install software from non-default repos in Qubes without setting a netvm for the template. We'll publish an edited version soon in case anyone else stumbles across it.
"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.
Would you have two different systems, one for low risk and another for high risk messages? How would triage and enforcement work?
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.
Someone who worked for the British Military told me back in the early 00's the US military (but could be any part of the US govt) had the ability to bowl up outside a building and "tune" into any of the pc they could detect. It didnt matter what floor of an office block they were on, how far away from a window they were, they had a special suitcase for remote accessing any and all pc's they wanted.
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.
Which is indicative of... squat. They could introduce an RSA-authenticated backdoor at any time, not unlike the one we had seen in xz, & no researcher would ever find out. In fact, chances are it's already there but even if it's not, Qubes is locking you into Xen platform regardless. The only viable means of gaining security against the NSA is full-source bootstrap from commodity FPGAs. Yes, you'll be stuck at 50 MHz for the time being but at least you know a backdoor-in-synthesis is so much more intractable. The physical surface area to protect is much smaller, too.
The complexity involved in targeting distributed, temporal backend systems like the ones being discussed here is sufficiently unreliable and risky that it’s easier and cheaper to just go straight for the people, or simply find another avenue.
Did you know about this previously? Then why did you lie previously claiming there have been no escapes?
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.
> Did you know about this previously? Then why did you lie previously claiming there have been no escapes?
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.
Point to literally anybody on the development team who claims it can stop a small team of professionals with a 10 M$ budget from finding a remote exploit. That is a tiny fraction of what a state actor can deploy and constitutes at best a low-end attack by a state actor who is actually targeting you. Just for reference, we can peg that at a first-order estimate of 40,000 person-hours or about 20 person-years, so a team of 20 with a whole calendar year to work full-time on finding a remote exploit. Even the developers themselves do not think they can provide protection against such low-end attacks.
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.
Where can I read how Qubes protects itself from any possible interference from Intel ME, which would be a low bar for a level of security users of Qubes aim for?
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).
Well, sorry, I mean, reading comments here and reading advice on QubesOS — they speak about airgapped systems, evil maid attacks, government vans that remotely snoop any computer etc. You don't need QubesOS to protect from known exploits, it was my understanding that people use QubesOS to protect from (real or imagined) state-level adversary.
Currently my "sensitive files" setup is a Pixel 8 with graphene, plugged into dock. A bit clunky (waiting for the desktop mode improvements), but not a bad security compromise.
This is a bit of a straw man argument. They’ve framed a specific architecture paradigm in a way you disagree with, so you shouldn’t deal with them ever?
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.
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."
And they would genuinely believe Xen is secure from NSA. Qubes is fun because it locks you into Intel processors; manufacturer notorious for sending cease-and-desist letters to researchers who had attempted to disable IME.
Alright, you don't understand air gapping so hard it's actually dangerous (to other readers, not you; I don't care if your ignorance burns you), so let's go over why the hell this lack of understanding is horrifying.
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.
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.
By prohibiting the carriage of USB media or only allowing ones which are under strict and constant supervision and lockdown, not to mention locking down any USB ports on the computer itself both physically and in software.
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.
I do understand air gaping. However I don't understand what you're suggesting to do in practice for The Guardian. Exchange files via QR codes? True air gaping is simply unusable for non-experts. I believe in a reasonable security.
In the article, they explain how they made a real, practical step towards a better security. Perfect is the enemy of the good.
Maybe you're not aware, but The Guardian's job description is obtaining and handling sensitive information. They are experts, ostensibly anyway. Their threat model is rightfully ridiculous and ridiculous threat models require ridiculous security measures such as air gapping which Qubes cannot satisfy. Reasonable is not enough given what they do.
If you are seriously suggesting a virtual machine is the same thing as an air gap, then no: You do not know what air gapping is. Not the least because there is literally no god damn gap with a virtual machine on a host computer.
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.
I’m not suggesting it’s the same as an air gap. I’m suggesting that the solution sufficiently meets their requirements to do away with the need for a bona fide air gap. In fact, that’s what is implied by the quoted statement in the article.
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.
>I’m not suggesting it’s the same as an air gap. I’m suggesting that the solution sufficiently meets their requirements to do away with the need for a bona fide air gap. In fact, that’s what is implied by the quoted statement in the article.
>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)
yeah. that's the least worse. but still much worse than even x86, which is already questionable but accepted as ok.
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).
Same access to most of the buses. unless you keep all your secrets in one core registers and maybe local caches. anyway, I wouldn't know. nothing from those cores is open besides the ARM abi it is built based on.
People using ‘cold’ hardware wallets are air gapping crypto to a degree. It’s really just offline key storage, which is as old as IT itself.
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.
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.