Introduction
Security for the home user is a challenge. Part of this is due to the inconvenience from additional security measure, part of this due of cost (which directly relates to users buying the software), and part of this is the options suitable for a home user.
Most people default to using Windows, or OSX which tends to run a lot in user space. Meaning, one piece of malware has pretty widespread impact on the system as a whole. Backups can help mitigate the damage caused by malware, but if the computer with malware is making said backups, then the backups can be a problem too.
Even people who use Linux aren’t really fully secure from this form of attack in many cases, for the same reason Windows and OSX users aren’t - and that’s more wide spread system access.
There are some mitigation strategies for those in Linux (and, fairly, in OSX too but some special effort needs to be put in place to make that work). While this post is primarily on Qubes [1], I feel talking about security mitigation techniques is still useful.
Mitigation in Linux
Mitigation from malware based attacks can be accomplished a few ways in Linux. One option is through the use of SELinux [2], which is a policy based enforcement available on Linux. It can do a lot, but is also a bit heavyweight and hard to configure. Another option is Firejail [3]. Firejail is considerably more lightweight than SELinux, but not quite as powerful. Both options provide great benefits such as:
- Restrict what applications have access to the network - You can restrict any app that doesn’t need internet access from having internet access.
- Limit filesystem exposure - You can restrict what an app can read. As in, what file paths can be accessed, or even visible, from the application’s perspective.
There’s a lot more that can be limited too, but the two above are some nice benefits. #2, specifically, is great. I’ve used Firejail, very, very often in the past. It helps to know that web browsers don’t have access to every file, and if compromised, their impact on the filesystem is very limited.
Not all’s perfect in this world though. Specifically ensuring that SELinux wasn’t set in permissive mode, or that Firejail was disabled, is the main drawback here. I’ve had times when I’d updated my operating system, and found Firejail wasn’t being invoked any more. I also found cases when xdg-open was invoked, that it’d launch something without it being properly firejailed. While these are likely configuration issues, they can happen, thus not perfect.
Mitigation in Windows/OSX
I’d be lying if I said there were no mitigation strategies in Windows. There is, but only to a limited degree. As I’m aware, there’s no sand-boxing of apps in base windows installs. And, to protect against ransomware, you need something like Bitdefender [4]. There may be something that exists, even if installed, that can achieve the isolation similar to Firejail or SELinux, but I’m not aware of it. I very rarely run windows, and on those machines, I use Bitdefender.
On OSX, things are a bit better. In OSX, there’s potentially less access, depending on how you setup your security and privacy. “Full Disk Access”, for example, has to be explicitly granted. This doesn’t help in many parts of one’s home directory (although, as I recall, there are ways to secure Documents), nor mounts or the like.
Of course, none of this mitigates network access, clipboard access, etc.
Universal Mitigation
There’s one mitigation strategy that can do better than all the above options, in my view, and that’s virtual machines. Virtual Machines, if properly setup with limited sharing between the machine and the host, can provide great separations of use. So, it’s entirely possible to have a virtual machine you use for email, a virtual machine you use for web browsing, and so on.
But, there’s a few catches for why this is a problem. Virtual machines rely on a secure host. So while a virtual machine guest can’t see outside its “box”, the host can see into the virtual machine. This means that unless you only use virtual machines, and never use your host to do something (like browse the web), you can still get compromised and all the effort to compartmentalize your work is down the drain.
There’s also the issue that now you have to maintain a number of extra machines, all with their own updates that need to be done. This can be time consuming, and with a chance of error. But, if you have the willpower and self control, this is a useful strategy [5], assuming your host is secure and you not only set up the virtual machines properly, but are committed to the behavioral change required to keep this secure.
Enter Qubes
Qubes claim is as follows:
Qubes OS is a free and open-source, security-oriented operating system for single-user desktop computing. Qubes OS leverages Xen-based virtualization to allow for the creation and management of isolated compartments called Qubes. [6]
The architecture diagram they have on the intro page is a great diagram for how this is setup:
At first, this may seem complicated, but it’s not as bad as it looks at first. The short version is that there’s a very lightweight Xen hypervisor host that sits in the front, and everything from the user interface (dom0), through apps are isolated in virtual machines called a qube. The nice thing about Qubes is also around how you can customize your workflow to fit your needs.
What this essentially does is add guard rails to the virtual machine mitigation strategy I mentioned above, helping you to stay within the rails (thus following best practices). If one component of your machine gets compromised, you can rebuild that one section instead of the entire environment from the ground up.
Qubes Templates vs Qubes
One important concept to go over is the difference between a template, and a qube. A template is the basis for a qube, but has a volatile user space (think your home directory), where a qube has a volatile system space.
A simple way to think of this is that the template is where you install your software, and the qube is where you run and use your software.
This separation provides some nice benefits. First, one template can drive multiple Qubes - meaning there’s a common set of software that can be available for the specific use cases that are separated in the interaction layer. This can reduce the amount of disk space used to achieve this type of setup to a very minimal amount. Also, when updating, you update the template and then it applies to the Qubes (either by restarting the qube, or restarting the machine).
Another nice thing about Qubes is the separation provided by them. Each qube has access to the template’s installed programs, but any writes to the volatile locations will result in automatic template reversion after it’s shut down.
To look at this from a malware perspective. Let’s assume you have an email qube, based off a common template. You receive a piece of malware, and it accidentally runs. That malware will affect your home directory, but not spread to the other Qubes on your system. Assuming you detect the malware, you can simply delete the email qube, and create a new one based off your common template and setup email. We’ll cover a better case dealing with attachments in a bit.
This can get even better if incorporating snapshots, where you can revert your qube to before the malware was installed.
Another useful qube concept are disposable VMs. These types of Qubes not only have a volatile home space (like templates) but also volatile system space (like Qubes). These are relatively safe locations to test malware, because whatever the malware does (as long as it doesn’t exploit Xen) will say in that disposable qube and will go away after it’s shut down.
In summary, we have the following types of virtual machines, and the state they keep:
| VM Name | State Configuration |
|---|---|
| AppVM | Volatile system space, persistent home - (Qube) |
| TemplateVM | Volatile home, persistent system - (Template) |
| DisposableVM | Volatile home, Volatile system |
| StandaloneVM | Fully persistent system |
Communication Between Qubes
The default behavior is that one qube (again, an AppVM, or VM), doesn’t talk with another qube on the system. So you can’t drag a file around between them, nor can you copy/paste text between them.
Because each qube is separate from each other qube, utilities had to be written to facilitate the communication between Qubes in the cases that they’re needed. There are three really useful utilities to help with this.
qvm-copy
qvm-copy [7] is a command that you can run from one qube to send files to another qube. Lets take that email example above. Lets say you get an attachment that you think is real, but could be wrong. You could use qvm-copy to copy that attachment to a dedicated disposable qube that can be used to test the attachment for safety. You can scan, open it, etc. in that qube and verify it’s not malware before opening.
This strategy is considerably better than having to worry about your Email qube becoming infected by opening attachments in that one. Instead of opening any attachments in the email qube, open/scan/check them in a disposable qube (DisposableVM) to verify them, then ship the attachment to the proper qube. For example, a workflow could be: Email qube (recv file) -> Disposable scan qube (check) using qvm-copy -> Work persistent VM (qube) for actual use.
This is primarily done through terminal commands.
qvm-open-in-vm
qvm-open-in-vm [8] is one of the most useful commands for someone like myself. What this command lets you do is, from one qube, to open the URL or file in another qube. My use case for this is in relation to org-mode (a system for documentation). In this system, I can embed URLs. I don’t want those to open in the the same qube where I’m running Emacs, but to run in another qube. So my hope is to set this up so that I can file those all off to another qube for processing.
This is also primarily done through terminal commands.
Copy and Paste
Even copy and paste is protected in QubesOS, which generally can’t be said for a lot of other mitigation strategies. In Qubes, you can copy and paste within a specific qube much like you would in any other application. But, if you need to copy and paste between Qubes, different effort is needed. You select the text in the source qube, right click and copy (or ctrl+c), then hit ctrl + shift + c. In the destination qube, you hit ctrl + shift + v, then ctrl-v. This may seem cumbersome at start, but it’s something you get used to quite quickly.
The reason why this is so important has to do with password managers. By now, everyone should be using a password manager, but if there’s some rogue process listening on the clipboard, your passwords could be logged. Since normal copy and paste functionality is limited to the Qube’s scope, any rogue process would capture the clipboard in that Qube’s space and no others. The intra-qube copy and paste allows you to copy and paste information that you explicitly want shared, with the specific Qubes that need that information.
How I’m Using Qubes
I’m a big fan of many templates, and many Qubes spun up from those templates. So I have a large number of these running, and each has their purpose. I do this primarily to ensure security is maintained among any one qube, and limitations are in place (including with firewall). My current setup looks something like the following:
- Minimal Template (Debian 11)
- Email - Just for email client
- GPG - WIP qube to tie in YubiKey and setup communication for GPG (Email and Personal)
- Standard Template (Debian 11)
- Personal Web - Web browser to sites I know are safe
- Personal - Development platform, my more “General Use”
- Work - Any access to work resources (e.g. email)
- Kali Community Template
- Kali - Security research
- Kali-dvm - Security testing (Disposable)
- Fedora Standard
- Untrusted - Web browser for general use, never logs into any sites.
- Untrusted-dvm - Anything I’m not 100% sure is safe (See email scenarios above)
- Standard built in Qubes (firewall, net, etc.)
What’s Bad About Qubes?
Qubes isn’t perfect, far from it in fact. While I absolutely love this system so far, and intend to make it my primary OS long term, there’s a learning curve. Some of the behavioral changes need to be thought out adopted to. I’ve seen people try to conform Qubes to their standard way of working, and the result is very questionable in terms of security.
Qubes also requires some very strict hardware requirements to get things up and running. When I started looking into Qubes, I realized that all my current machines couldn’t run it for various reasons. So, in the end, I bought a System76 laptop for the sole reason of using Qubes. One of the largest challenges many may face is the issue with NVIDIA cards in many laptops and desktops. This is what made it hard to install on my workstation.
Luckily there are some workarounds for these problems. Version 4.1rc2 [8] was released on November 17, 2021. This resolves a lot of the issues with chip set, but may not with NVIDIA cards.
My personal feeling on Qubes is simple. Qubes makes a great general purpose, non-gaming, system. So the simpler the specs of one’s machine, the easier it is to setup Qubes. Personally, I want to reduce to having 2 primary machines. One being this System76 laptop that I’m generally using. The other being my Linux workstation that can do more heavy lifting that I can secure in alternate ways (SELinux/Firejail/VMs) and that can be used for stuff like gaming, running models, and so on. I personally have no intention on attempting to get any gaming working in Qubes, it’s not worth the effort and attempts to turn Qubes into something that, I feel, it isn’t intended to be.
Where I’m going from here?
I’ve only been using Qubes for about a week to a week and a half now. My workstation is still my primary use box, but I’m waiting for firmware updates from System 76 and the finalization of 4.1 before I formally move over. If 4.1 takes a long time to be fully released, I may jump as soon as the firmware update from System 76 has been deployed.
In the meantime, I’m setting up Qubes and learning how to automate parts of my process. The GPG qube I mentioned earlier is one such task. Little documentation exists on proxying the YubiKey in this fashion, and I want to contribute. I’m also looking at Qube backups, what should be backed up, and how. I’m also investigating work on network shares, and getting everything working so I can use this in “everyday” activities. I’m only about 50% the way there, at this point.
At some point, I intend to help with development of Qubes. I strongly believe in their mission and goals.
How to Test Qubes
I strongly encourage people to try Qubes. It’s a definite departure from the normal use, and will take some behavioral changes to make work, but it’s really solid. The best way to test it is on an external drive. A USB3 SSD or NVME would suffice. Start with the ISO download from https://www.qubes-os.org/downloads/ and follow the installation instructions on https://www.qubes-os.org/news/2021/11/17/qubes-4-1-rc2/
Make sure you’re wearing your security hat in all this. Validate the cryptographic hashes.
When installing, pick the defaults. Whoonix is optional (and I don’t run it here), and I suggest the Red Hat base template for Sys/Firewall/etc. There have been some tickets on Debian for these.
Once Qubes is running, go through their Getting Started guide at: https://www.qubes-os.org/doc/getting-started/
If you run into issues, there’s plenty of places to get help. This is especially good if you run into bugs that you can report. Their GitHub repo is at: https://github.com/QubesOS/qubes-issues
Qubes is very flexible, but not as flexible as other Linux distributions. I personally feel a lot of the decisions they made in architecture design are for the best, security wise. I strongly recommend that if something feels like “too much work” to do, or if there’s little documentation on what you’re trying to accomplish, then you seriously consider if Qubes is the best place for it. Don’t be afraid of dual booting and/or keeping multiple machines.
