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.
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.