Hope you don't mind the flamboyant title, but, I truly do believe that the small attack surface of the heavily minified Xen hypervisor, networking stack, GUI virtualization, and much more Qubes OS employs + the Whonix intergration implemented in this project (making it a Windows-Whonix-Workstation; thus also giving it Tor-only Internet access with stream isolation between other VMs) makes it the most secure and private way to use Windows currently available today. Those are just the two main points, besides that, there is also the fact that because everyone using this project is both having their Windows VMs set up in the same way and running Qubes OS, that greatly helps to keep the OS and hypervisor fingerprint homogeneous across all users. This effect will only grow stronger as the Qubes OS userbase increases. Lastly, if the user wishes to reset their fingerprint, they can automatically do so by reinstalling Windows with this project.
Of course, I would be happy to go into detail and answer questions about any of this.
Note that this project is the product of an independent effort which is not officially endorsed by Qubes OS or Whonix.
So, qubes is an OS where each "process" is more or less an isolated Xen VM, is that a good starting point?
I have so many more questions about qubes than your project, but I've been struggling to find a good way to run Windows VMs on Linux reliably and your project looks great for that. Once I get a qubes os box up, I'll give it a try.
Qubes OS assumes that it's impossible to ensure every single application you will be running on your computer is secure. Therefore, the best way to secure your computer is to isolate all of the applications as much as possible so the exploitation of one doesn't lead to compromise of another or the entire system. Through (heavily minimized) Xen VMs is the most basic way Qubes seeks to provide this isolation. However, it goes much further than that into the networking stack, audio stack, GUI stack, and much more. This all lies on a security principle known as "security by isolation" or "security by compartmentalization".
You typically have different "qubes" (VMs) for all of your different day-to-day tasks/activities. Although, not necessarily each process.
By all means give it a try, you won't regret it!
Question: what does GUI virtualization actually mean? Does that mean the OS runs windowed in your existing DE? I’m guessing that means no HW acceleration. Is it possible to selectively pass through the GPU for a KVM-esque experience?
No HW acceleration by default as of now. It's possible to passthrough a GPU to the Windows VM in order to get acceleration, although, you risk exposing complex hardware directly to the VM which comes with many security implications: https://www.qubes-os.org/doc/device-handling-security/#pci-s...
Note that in practice, passthrough works best with AMD GPUs; I've heard few reports of success with Nvidia GPUs.
Would love to eventually see Windows apps behave like Linux apps on a window level, instead of displaying the whole Windows VM.
That feature is currently in the works (officially speaking) for Windows 10; for Windows 7 it already exists (although it has of course been EOL for some time now).
However, I do recall finding a report of someone successfully using WinApps (https://github.com/Fmstrat/winapps) as well as RDP running in a Linux (GNU/Linux) qube to effectively also have Windows applications displayed on a window level. Security-wise it still holds up because that Linux qube, if compromised via the RDP connection, will lead to the disclosure of no additional sensitive information because it's only being used for that single purpose. As long as you have ample RAM to support it, this could work very well.
I'm in the process of submitting a patch to SeaBIOS so it will no longer be necessary to patch this in yourself.
GPU virtualization is a very difficult thing to do securely, I think VirtualBox said it best in their hardware 3D acceleration documentation (https://docs.oracle.com/en/virtualization/virtualbox/6.0/use...):
"Untrusted guest systems should not be allowed to use the 3D acceleration features of Oracle VM VirtualBox, just as untrusted host software should not be allowed to use 3D acceleration. Drivers for 3D hardware are generally too complex to be made properly secure and any software which is allowed to access them may be able to compromise the operating system running them. In addition, enabling 3D acceleration gives the guest direct access to a large body of additional program code in the Oracle VM VirtualBox host process which it might conceivably be able to use to crash the virtual machine."
It's currently a problem yet to be solved.
No need for chatty telemetry at Windows and app level in the background.
While the suggestion does not encroach inside the Windows’ VM to perform “their” CPU suspension, it is a better idea to process suspend the host’s KVM underlying that Windows VM. Hope that the guest’s video driver doesn’t leave its hardware in an inconsistent state for the host’s main video driver and its entire system.
This tidbit needs to be made a prominent FAQ on Qube website.
1. A dev machine. I have a persistent and static disposable version of this build.
2. An anon build connected to whonix. Again, I have persistent and disposable versions.
One thing I had to do was compile the QWT v4.1.65 iso and install the resulting msi. Other than that it all works flawlessly and provides great peace of mind for those occasions when I have to use Windows.
Otherwise, feel free to open an issue on the Qubes issue tracker and the Core Team will look into it.
