I think the Debian 13 template VMs shipped with Qubes OS do not have enhanced security, so I wonder how secure is it in the below scenario:
You opened up your VM, which has internet access and store a lot of your encrypted files. You decrypt those files every time using a password which you almost never forget. Then someday you left the VM open, connected to the internet for an extended period of time, say, from 12h to 24h. On the 16th hour, you type in your password and decrypt the file as usual, but realized that there may be some hacker who came and installed a typing recorder on your VM. Although you know the typing recorder won’t survive a App VM restart, you have just typed your password in this session of the VM. How risky is it to have your password recorded and sent to the hacker?
Setup something like split gpg, where you have the gpg private key in another offline VM and confirm access via this dom0 popup. Then when you type the password, you don’t type it in the VM with the encrypted/decrypted files.
Mind that if you decrypt the files it doesn’t really matter that the attacker doesn’t have your password, because he has what the password protects.
Although you know the typing recorder won’t survive a App VM restart
Unless the malware is installed in /home or /rw (or that one other AppVM persistent path I don’t remember rn)
I think the Debian 13 template VMs shipped with Qubes OS do not have enhanced security
Yes, and it even has passwordless sudo by default (I think, I didn’t use it in ages). So its basically just a normal debian (with passwordless sudo) - which however is still isolated by XEN/Qubes.
Do you need your encrypted files to be available in a Qube that has internet access? If you can keep them encrypted/decrypted in a VM without netvm, that might be better. If you need them in the VM with network access, use sth like split gpg to at least protect the other files that are not encrypted at this time, as in then the attacker can see the one decrypted files, but can’t decrypt the other files. Also you should limit to what exactly you access on the internet - if its just a single website, configure the firewall so the Qube can only access this single Website, even if you click on sth else by accident or so.
For non persistent malware you could administrate / manage the files presences in the appvm and create a named disposable vm (makes the qrexec rules more easy so it can use split gpg to decrypt files) from the appvm and only have this one access the internet. If it is infected, it is not persistent.
You should use disposable for any risky task, example: archive decryption.
Second layer, is to access data within network isolated disposable.
As storage for future access, use network isolated appvm - while “storage” mean, that you never access to data within this appvm. Move data to disposable or network isolated disposable for any data manipulation tasks.
Also, prefer to remove any software that may read data from template you use for storage appvm: libreoffice, browser and etc. Consider to use antivirus, like ClamAV: How to Set Up ClamAV on Qubes for time to time data scans within up-to-date copy of your network isolated appvm storage.
Also I think there is a makeshift solution to this problem. Simply disconnect from the internet before AFK will eliminate the chances of attack I think.
No. Nothing prevents a malware from waiting to broadcast after the connection establishes again. The idea of Qubes is that you segregate your workflow in different compartments.
You don’t need to have many qubes, you can use only the defaults work, personal, vault, and disposables from default-dvm and it will already be much better than doing everything in a single qube. As an experiment, do the following, download a PDF, open the file manager in the qube and click “View in disposable qube”.