I’ve been using Qubes OS for over a year now, with the assumption that if I reboot an AppVM (or domain) that had been hacked or infected with a virus, the hack / virus would disappear. My device had been compromised in the past and this is why I switched to Qubes.
Now, I keep reading on various forums that service VMs (sys-net, sys-firewall, sys-usb) should be made disposable for added security. Why? Can a hack / virus persist in the file system upon reboot?
To make things more complicated, I installed youtube-dl in anon-whonix AppVM and it still works upon reboot. AppImages run directly in the AppVM (and this is not recommended). I am not an IT expert. Doesn’t this indicate that some forms of virus / script / hack can persist?
And thank you for this forum. It’s been incredibly helpful.
Yes. In short, for non-disposable VMs, malware can persist in the home folder, which is not destroyed.
The answer is yes under the circumstances @427F11FD0FAA4B080123 described.
By taking advantage of Qubes’ features you minimize that risk significantly. Some measures include:
- web browsing only on disposable VMs
- open PDF in disposable VM
- edit word and presentations in disposable VM.
Essentially anything that avoids running programs directly on your (non-disposable) AppVM is a good mitigation. You can think of AppVMs as the hub which you only use to see the file explorer and open files in dispVMs.
Of course, here we are never talking about malware that can punch though the XEN (the virtual machine manager), which is harder to pull off.
Why does this happen?
Note this is a not very technical explanation and clearly sacrifices technical accuracy for clarity.
For AppVMs your /home/ is persistent but programs are inherited from it’s templateVM.
Although it mitigates against traditional malware that tries to persist in the programs, it’s not entirely accurate to say that it can’t persist across reboots on the /home/ folder.
One particular example is the program /rw/config/rc.local which is persistent across reboots, and is executed every time your machine boots.
I believe the following work by @tasket includes some mitigations against this, but I think it’s a bit advanced and the above mentioned mitigations should be already a step in the right direction.
Related:
Thank you for your helpful replies. Now I have two questions, and I apologize if they’re quite basic.
- If someone is walking the ten miles two install and use Qubes OS, why isn’t Qubes-VM-hardening - one extra mile - included as an option in Qubes OS?
- Where is the download button in GitHub? Being an non-IT end-user for Qubes OS, GitHub continues to challenge me. How can I download Qubes-VM-hardening?
And is such a third party add-on considered to be safe?
To be included in Qubes in needs to go through the following process: (it’s a bit technical, though, but you can get the high-level overview of the process)
Maintaining (and making sure of the safety) of additional software is costly, as it requires manual review by a Qubes developer. But there are already some contributions that made it though.
A note on trust
By installing a third party package, there is some due process needed. Chris (aka. Tasket) is a known community contributor, with a long track record of contributions. So you need to figure out for your particular threat model and some other variables you should accept the level of trust or not.
When you download the code from github, you should verify that the code is signed by Chris’ GPG key, but that may itself be a roller coaster on its own.
If this were an official package it would all be easier.
Please, make sure you understand the consequences before proceeding.
Look for the green button: (and if needed, after that you can also hit the ?)
There’s an open issue for it:
Doesn’t look like it’s in the contrib repo, but if it were, you could install it (potentially) more easily:
Thank you for your answers. I have one more question: If home and persistent storage are hacked, do these hacks get backed up too in the Qubes backup? I’m thinking of a scenario where someone suspect a hack, so he/she backs up and then re-installs a fresh version of Qubes OS, then restores the backup. Would such a procedure remove the hack?
Of course, this depends on the nature of the hack.
If the attack came by an infected file downloaded to private storage,
then that will be included in the backup, and you may open or run it
once again.
If the attacker has installed a backdoor in the private file system that is
triggered on certain events, that will be backed up and restored on to
a new qube.
If an attacker has installed a backdoor in memory, that will not be
backed up.
If an attacker has installed a backdoor in system storage, that will not
persist.
If an attacker has broken qube isolation, and is able to transfer data
between qubes, whether by qube-rpc or some other mechanism, then you are
lost. You do not know if this is the case unless you are running some
form of IDS.
As far as I understand it, if it had persistence it will keep persistence when restored, as that is a principle of a backup - restore everything as it was.
But the backup mechanism is a way that restoring a template / AppVM should not affect other VMs (of course, assuming an attack that does not affect XEN).
It is very common… not just happening. I shut of USB from BIOS and use it only of line 99.9% of the time. If you can get a pre 1998 ethernet network card that also helps. They are a hot item in Japan.
Thanks you everyone for your responses. Much appreciated.