VM Isolated Network Support
While the point of AirgapOS is to remain disconnected from a network, we -do- need a way to tunnel information back and forth to a network securely.
For threat models where you have other mitigating factors to sophisticated side channel attacks, such as when you are only dealing with one -part- of a key, then having a way to tunnel information to and from the internet without actually without exposing a network stack to the ceremony operating system starts looking like a fantastic usability tradeoff.
Such a setup would make it much easier to justify doing more operations in a security focused. operating system.
This is not a new idea. QubesOS isolates the network via the "sys-net" vm, while keeping "dom0" entirely isolated from network attacks on the other side of a hypervisor barrier.
We intend to take exactly the same approach here.
Ultimately we want systems that have network devices installed, to automatically boot a VM to contain them, and do any optional network operations in this distinct virtual machine.
Even for use cases where you are -not- using a network, having the network devices jailed still limits attacks from any malicious firmware that might be present in those devices.
For threat models where a single key will be hot in a single local machine, say for key generation ceremonies, it is probably appropriate to just remove the network cards entirely, in which case this new optional VM functionality would never start at all.
Another benefit of having Qemu available on AirgapOS, is for ceremonies that require ideally doing multiple offline operations in one boot that each touch software supply chains of varying level of trust. Each of these could be isolated to a virtual machine to avoid contamination of the host OS, allowing AirgapOS to be an immutable and deterministic alternative for ceremony use cases previously only possible on Qubes.
