Basically, let’s say I want to transfer some files from qube A to qube B using file manager (or command line). And these files are clean, but either qube A or qube B may have been compromised by malware.
How much attack surface is there in the file transfer interface? How does it work? I can see a mounted drive icon appearing in the file manager when I do this.
And how likely will qube B get compromised if qube A is compromised (or vice versa)?
I think there is no clear answer. If you transfer plain text file and open it with something simple like nano, unlikely there will be any problems. In theory text editors can have critical errors, but I feel safe when I transfer “simple” files between qubes like text, images, archives etc
I’m not talking about safety of the files themselves. Let’s assume they are clean.
But if there is malware running on one of the qubes, either in the receiving qube or in the sending qube, how easily can it propagate to the other qube?
edit → @OvalZero thanks, I’ll read that.
Considering recent QSBs (118 and 119) it seems like there are plenty of eyes on qvm-copy at the moment, which means it should be more secure thanks to the recent patches, but also has a decent chance of new vulnerabilities being found.
p.s. read them if you want to get into details, and study how related binaries work (qfile-agent, qrexec-client-vm, dom0 qubes daemons, xen vchans…)
Which file manager is that?
I’m guessing what you’re seeing is related to an implementation detail on the receiver side. It’s setting up a bind mount on the directory ~/QubesIncoming/source-qube-name/ - a kind of trivial bind mount, from the directory to the same directory - while the transfer is in progress. That bind mount doesn’t really have any function for the file transfer itself. But it’s there to prevent user error; specifically, it’s trying to prevent the user (i.e. you) from moving contents out of the directory during the transfer, which otherwise could be a problem if the sender side is malicious:
The inter-qube filecopy protocol is basically intended to be simple and robust enough to make the answer “very unlikely” in both cases, hopefully. At least compared to other file transfer methods.
I see this behavior in Thunar and clicking on the mounted drive opens ~/QubesIncoming/source-qube-name/. Glad to know it’s intentional and the reasoning behind it (I had wondered, but never thought to ask).
The safest mental model is that qvm-copy-to/qvm-move-to transfers the file through the inter-qube service, but it does not make an untrusted file safe. Keep the destination qube disposable or otherwise isolated until the file is inspected, and avoid opening it with a parser that handles active content. If the source is compromised, use a one-way workflow from a disposable qube and copy only the specific artifact; if the destination is compromised, assume anything written there can be altered, so verify hashes or signatures in a trusted qube.