Hacker News new | past | comments | ask | show | jobs | submit login

Those are strange requirements.

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




>Those are strange requirements.

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.

[1]: https://news.ycombinator.com/item?id=39951031


Did you even read the comment you're replying to?

>If your threat model can be satisfactorily defended using virtual machines, you never needed air gapping in the first place.


I did.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: