Shortly after last years FIfFkon I installed QubesOS R3.2 on my notebook. I was a bit sceptical at first, as my notebook is not SOTA, never was. It only has 4GB of RAM and no SSDs, which is something like the minimum the projects states on the list of requirements. But a friendly humanoid being told me I should try it anyhow at FIfFkon, worst case it wont work.
Also, the project claims, that QubesOS is
A reasonably secure operating system
in their header and I wanted to have a look at their way getting it reasonable. Reading further, they say that
Qubes takes an approach called security by compartmentalization, which allows you to compartmentalize the various parts of your digital life into securely isolated compartments called qubes.
which made sense for me. So I downloaded the ISO file, checked the checksums etc and installed it.
What makes QubesOS different from other GNU/Linux distributions is, that you are not doing all your stuff on the same machine. Instead you have several Xen hypervised virtual machines in which you run small portions of your computer stuff in. Portions that belong to each other, or that you think is not too bad to loose if one of your VMs is compromised. So I ended up with one for email, one for browsing my Friendica node and the network, one for regular browsing, one for online banking, one for office work and one for developing Friendica. So should I catch some malware via a malicious email (e.g. an attachment I did not open in a throw away VM mistakenly) only the email VM would need to be redone (or set back to the backup point) but my online banking was not compromised.
Shown in the screenshot (taken from the QubesOS screenshot collection) above you see several application windows belonging to different VMs, indicated by the colour of the window borders. The different VMs cannot interact with each other directly, so you have to do some work from the user interface to get them interacting. This may be opening a command line and execute a commend, or 1st copying some marked text to the special clipboard. It's a bit unconvenient, but it also needs a bit to be. Do I really want to do this now? It just prevents you from accidentally doing something stupid. Refreshing in an age where we are trained to hit the yes-button. And it does not disturb normal workflow within an application either.
To access the different VMs and the applications therein, one can configure the main menu of the window manager. You simply select the applications that should be listed in the VMs submenu. For instance for the Friendica development VM I had
Friendica -> Firefox -> Gnome Terminal -> geany -> gvim
as entries in the menu. And yes, I switch sometimes to geany as editor instead of using (g)vim which I use most of the time. While online banking only contained the Firefox entry.
As a user it was not important that I had chosen Fedora as OS underneath the banking VM and developed Friendica under Debian. As a user I just opened Firefox from the banking VM to access the online banking portal which was the selected start page of the browser in that VM and actually one in the very limited set of domains accessible by that VM at all.
What about updates?
With all that VMs flying around, you have to manage updates somehow.
QubesOS does this by having a few template VMs from which the VMs you are actually working in are derived. Most of the files in the derived VMs shared from their parents upon starting the VM. So when the Debian template VM gets some updates, and the VM managing application is checking that regularly, your working Debian based VMs are unaffected by the update process, until you restart them.
So in my case, I sometimes had two template VMs updating while I was working in one other VM and browsing in a forth. Once the updates got applied and my work reached a point to have a break I would restart the work VM to continue.
That all worked nicely, even while running on battery, but I still had the feeling of running the OS on the lower limits. Which is not really fun. Especially not as I don't feel the need to have such security on my personal computer. (And I'm sure I discover that I should have felt so tomorrow.)
R3.2 of QubesOS ships with old versions of Fedora and Debian Linux as guest OS in the virtual machines. After updating both to current version I had no problems regarding my hardware and almost not regarding the software as well. Well as said before it felt a bit slowish as the hardware is on the lower limits of the requirements, but that was expected and so not really a problem.
Almost regarding the software, as I did not manage to get my Nitrokey Storage, which I'm using for 2FA, working with the application VMs. So using web pages where I added 2FA for securing my login got off limits under QubesOS and thus while working on the notebook.
In the end, that was the reason for the quick end to my intermezzo with QubesOS. On the other hand this problem is part of their necessary compartmentalization as USB thump-drives are one gate for attackers to get into your sensible data. So I can clearly see the reasoning behind my problems with that setup. If I would have felt the need to have QubesOS running, I would have find a different setup for the 2FA secured pages, but my current needs are different ;-)
The documentation for QubesOS is well written to give you a nice start and something to dive into. So if you are in need of a reasonable secure system and have recent hardware, you might want to give QubesOS a try. But be aware of some learning that has to be done.
Note: Screenshots presented in this posting are taken from the QubesOS Screenshot collection used for presentation here only. Thanks for providing them!