In my work in the digital sovereignty working group of the German Gesellschaft für Informatik, I created a paper outlining the typical risks we are confronted with using standard proprietary IT systems like Windows and possibilities for mitigating these risks, including the use of Qubes OS.
The paper is structured as follows:
1 Awareness of the risks of IT use
2 Vulnerabilities and risks
3 Causes and originators of threats
4 Improving technical protection
5 Necessary changes in IT usage
6 Conclusion
You consider use cases within SMB and enterprises?
In order to make QubesOS suitable business solution, we must have option for central management of dom0’s over different devices for remote audit, backups and security management.
Any type of such solution compromise QubesOS security model.
Except of a situation when QubesOS used by IT system administrator as his own endpoint to isolate management interfaces from remote support connections for example.
But he should take personal responsibility in all aspects of his QubesOS device.
It’s still a work in progress, and we are considering where to put it finally. And still, further changes may occur if someone in the working group becomes active.
I have a question about your description of Qubes here:
Use of application software in separate virtual machines that receive their soft-
ware as copies from their assigned templates when they start up and whose soft-
ware is destroyed again when they shut down, so that no malware can be permanently installed there
(Honestly, this probably isn’t the best place to ask this, but this is what piqued my curiosity about this feature)
Your claim here is that no malware can persist because software is destroyed upon shutting down the VM. But what if the malware is, for instance, an App Image or a file? Then malware can definitely persist in those cases, no?
I had to simplify the description somewhat because the intended target audience probably never heard of Qubes and its template concept.
Surely, malware that’s stored somewhere in the user directories of an AppVM, like a macro virus in an office document, will survive the restart of that AppVM. However, it will remain dormant until the document is opened again, and even then, it will not be able to infect the system part of the AppVM permanently, because any data it stores there will be destroyed upon the restart of the AppVM.
The only way for malware to affect an AppVM permanently is if it resides in a document or an application stored completely in a user directory, and if that document is opened automatically or the application is started automatically whenever the AppVM is started. But I guess that is a rather exotic situation that should never occur in the careful usage of AppVMs. Still, even in that situation, the infection will be restricted to this one AppVM and will not be able to propagate into other VMs, especially not into a template.
Here, I have to stress the importance of the advice of @KitsuneNoBaka to avoid appimages, which, by their concept, are a clear violation of the separation of user data from system structures, and therefore should never be used if you want to rely on the protection provided by the template concept.
It depends from what you are mean with “install” of malware. If you mean, that malware is persisted as file somewhere in the users home folder, yes.
If you mean “install in the system, so that it can infect other system parts or other users and started automatically, when the system starts”, then no.
I think, the second description fits the traditional meaning of “computer virus” or “malware” better then the first.
Of course, Qubes OS cannot protect you from incidents like “Glassworm” or “Shai Hulud”, but that fact is shared with almost all other Operating Systems.
Every place, that a user can write to is potentially a place, where unfriendly software can resist also.
I would specifically focus on the fact that US government agencies have SecureView licensed to them for free to be used in high risk environments, and it is proprietary. Qubes fills this gap for Europe like a charm.
There are many people who would never touch something as complicated as Markdown; for them, PFD is about the maximum they are willing or capable of using. To prevent losing them, Qubes requires a method to provide support for safely using PDFs, which can be achieved quite easily using disposables, or, for a more comfortable solution, by utilizing the dangerzone-qubes tool.
This may be of interest for the Qubes community, since Qubes is an important tool on the way to gain more independence from proprietary environments, achieving better independence.
Their architecture is quite similar, as both are based on Xen, but while SecureView is quite static to support multiple classification levels, Qubes is flexible enough to support everyday computer usage. Knowing Qubes, the structure of SecureView looks quite familiar:
In my opinion, the security of Qubes is better than that of SecureView, because it has such features like the template concept and disposable VMs, which are invaluable for work in unstructured environments like those that many Qubes users are working in.
From a European view, it is now doubtful if using SecureView would be a good idea, looking at the current erratic American politics …
Qubes-os users have convert-pdf, but most people do not. PDF is notorious as an infection vector. Its a programming language. Plain text is the safest and most compatible file format. I brought up markdown as a plain text compatible option if you wanted to add some formatting.
That’s exactly the reason why they should use Qubes! Unfortunately, most users seem to be content with using systems that can be easily attacked via compromised files (PDFs, office documents, JPEGs, and so on) they get from external sources. So, a reasonable point of view would be to prohibit the use of such external documents for users of non-Qubes systems and allow them only plain text. But I have some doubts whether that would be regarded as acceptable.
In Qubes, if you use convert-pdf or dangerzone-qubes, all dangerous document operations are done in disposable VMs, which are afterwards destroyed. Any attack performed from such a document will be contained in the dispVM and cannot spread any further into other VMs or dom0, unless there is a severe security flaw in Xen - but then you have lost anyway.
Thank you for the quite comprehensive discussion. There are a few things I observe in very different dimensions.
Whenever it comes to system security discussions, which is one part of your text, the attack surface is addressed in relation to the technical architecture of the system under consideration. I wonder if it makes sense to chose a presentation that follows the QubesOS architecture, if this discussion does not yet exists somewhere else.
Second, concerns the security updates i.e. the maintenance of security over time. IMO there should also be a requirements on the QubesOS community expressed, that security researchers must find support to report vulnerabilities they might find. There should be some kind of process that can be followed.
Last not least, I wonder about the more hardware oriented protection, where machines are made easily accessible to storage devices like USB sticks. The PCIe is specifically crucial for that (cmf. Rothwell, Exploitation from malicious PCI express peripherals, https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-934.pdf). But maybe this is a non issue for QuebesOS installations.
The paper was originally intended for non-technical people who had probably never heard of Qubes. So I had to omit many specific technical details. But it may be a good idea to create a more technical version for the Qubes community. I’m thinking about it.
