Qubes
Limiting fallout
I've always liked the idea of keeping unrelated things separated on computers.
Separate browser profiles
As the browser is probably the main vector of "bad stuff happening" on an up-to-date Linux machine, I started off using different Firefox profiles. This (I hoped) meant that naughty code would only get any saved passwords in that profile.
Also, separate profiles would mean that cookies and tracking wouldn't be as effective.
However, this meant I was still running Firefox as my normal user account. You know, the account with all my documents, SSH keys, Keepass databases, files, pictures, etc in it.
So any compromise of that account was effectively total. On a single user machine (which my laptop effectively was), the main user account was almost of as much value as the root account.
Separate users
So I started creating separate users for each Firefox profile.
I had an additional normal user (ff) for normal Firefox use, a finance user for financial stuff, a Google user for Google stuff, etc etc.
I didn't run any Firefox as my main user - I just needed to run
xhost SI:localuser:ff && sudo -u ff firefoxto fire up Firefox. (I configured sudo not to require a password for this to lessen the friction)
This worked quite well.
(I'm not quite sure how much access the running Firefox had to key-presses from another user, but it was better than nothing.)
There were obvious issues - anything downloaded in ~ff/Downloads/ wasn't accessible to my normal user, and anything in my normal user home directory wasn't accessible to the ff user - but this was of course the point.
And this is what I used for a good while.
The grand old Dame
My main laptop was a 2009 HP Elitebook 8530w that I was given after being made redundant. At the time, it was a beast. 4GB RAM, dual core, really well made, with a beautiful keyboard and touchpad.
The only things I've replaced on it are the battery and I swapped the old spinning rust disk for a hybrid SSD.
It still runs everything I want, including IntelliJ.
Yes, I've been using a laptop that's 10 years old until just recently.
Nowadays, that spec is a little bit wanting, and it's probably not going to last much longer.
So I started looking at new laptops.
Run everything in VMs
I decided that there was probably a better solution than this system of using separate user accounts, so I initially thought that I'd buy a laptop with lots of memory on it, install some Linux on it, and run different things in different VMs.
So, log in to the "base" Linux, fire up a "dev" VM, log in to that, start IntelliJ, and start working.
It would have worked, sure. But it felt a little cumbersome.
And then I found out about Qubes.
Qubes
Qubes is essentially a compartmentalised single-user operating system based on Xen, which works on the principle of limiting the fallout that comes from being owned.
Xen is a Type 1 hypervisor, as opposed to the Type 2 hypervisor solution that I was thinking of above.
A Type 1 (bare metal) hypervisor is where the hypervisor runs directly on the metal (such as Xen, VMWare ESX)
A Type 2 (hosted) hypervisor runs on top of an operating system (such as Qemu, VirtualBox).
Xen is, I think, what Amazon AWS instances run on.
In Qubes, everything that runs is a VM (that they call a qube). There's the main VM (dom0), and then the rest are normal VMs.
The idea is that you create lightweight VMs for your usual work - shopping, browsing, media, work, etc. These VMs by default aren't aware of network hardware, or PCI or USB devices.
In fact, in order for them to even get on the network, they need to communicate via a special VM (sys-firewall) which in turn communicates via sys-net, which is the only VM in the whole system that has the networking hardware exposed into it.
Even the master dom0 VM doesn't have network access. This strongly encourages you to not use it for anything other than managing the other VMs (qubes).
[root@dom0 ~]# ifconfig -a -bash: ifconfig: command not found [root@dom0 ~]# route -n -bash: route: command not found [root@dom0 ~]# ping 8.8.8.8 connect: Network is unreachable
It's also (deliberately) hard to copy files or clipboard contents between VMs. In fact, I couldn't work out how to copy the output above from dom0 to the VM I'm writing this in, so I had to type it out manually.
But that's the whole point. You segment your various activities, and there should be very little that you need to copy between VMs. Why would your IntelliJ VM need anything from your shopping VM?
There are three main types of VMs.
Standalone VMs
These are what most people will be familiar with. A chunk of disk, an allocated amount of CPU and memory, and the rest is up to you.If you try Qubes, and don't understand the other types immediately, just use these until you do.
Template VMs
Because it doesn't make sense to have a full 2GB copy of Fedora for each different VM you want Firefox for, Qubes has the concept of TemplateVMs. I'm not sure the word template is exactly right - template implies to me that it's used at creation time. This is more something like a parent VM.A template VM has all the software installed in it you need.
Then you create VMs based from that template. However, it doesn't just use the template VM for creation. What it does is create a sub-VM that contains a writable /home, while the rest of the VM is the readonly parent template. Any changes to /home are persisted, but changes to the rest of the filesystem are thrown away.
Using template VMs has the advantage that you only need to update the software in the parent, and then all the VMs based from it will pick up the updates.
Disposable VMs.
These are VMs that when fired up start running, and don't save anything. Useful for your transient browsing needs.There is also by default a couple of "Whonix" VMs which give you Tor access should you want it. You can start Tor browser in one of these VMs to use Tor directly, or I think you can create other VMs to route all their traffic through the Tor gateway VM.
It should be mentioned that Qubes takes care of starting the VMs for you.
In the start menu, you have entries for each of your VMs, and then a submenu for the applications inside it.
For instance, my start menu has a "dev" section, and within that, options for IntelliJ and Terminal.
Selecting either of these will start the dev VM if it's not already started, and then run the required application, which appears on the screen after a few seconds. The window manager colours the border of all running applications, so you can easily notice which one is which.
All of this works a lot more slickly than my run-KVM-manually-in-Ubuntu solution that I was thinking of doing before I found Qubes.
Problems
There are a few little niggles still (which are often for security based reasons)
Any external USB keyboard plugged in is disabled, which means I can't keep my laptop closed, and use external monitor, keyboard and mouse. The password entry screen only functions with the laptop's built in keyboard, and the screensaver kicks in from time to time because it doesn't recognise that anything's being typed.
There are also problems with Nvidia graphic cards, so that "steam" qube isn't going to be used for a while.
It took me a little while to work out how it all hangs together, but with a little perseverance, and reading some of the very good documentation that the project has, I'm coming to like it.