Hi everyone,
I have a few questions regarding qvm commands, particularly qvm-copy, qvm-run, and qvm-move. What prevents malware from utilizing these commands, especially in environments with passwordless root access? While it’s possible to disable passwordless root, has this issue been addressed? In theory malware can still be transferred using qvm-run to dom0.
If I understand you correctly your assumption is wrong.
You had to copy the malware via dom0 terminal command from an owned VM to dom0 yourself before a malware could do some real nasty things. That’s a layer8/9 problem.
user@someVM ~ qvm-run-vm -- dom0 ps -aux
will exit with
Request refused
Btw. are you a bot?
…? why would I be a bot?
Please don’t mind. I just like social Turing games.
Ohh, yeah, I don’t blame you. My username is randomized too.
Anyway, you’re right I forgot that you need to run the qvm-run command inside dom0 to copy files from other VMs. However, even with qvm-copy or qvm-run, malware could still theoretically spread to other VMs, right? How can I address this issue?
Run this command from a Terminal of untrusted qube. And see what happens:
qvm-run personal ls
Command not found, but qvm-copy/move can still be ran though, and essentially be spread out to other VM’s
Indeed you can install it in untrusted by installing qubes-core-admin-client package. But even if it is there and you ask it to execute a command in another VM, you will see a warning that it is trying to execute a command in another qube without having sufficient privileges.
As for qvm-copy and qvm-move, the default behaviour is the popup confirmation dialog (with Dom0 in tile) which asks you to allow it to copy or move the file to destination VM. But you could click cancel. Or there is Policy Editor, where you could always ban specific qube to be able to copy/paste to any other qube. The documentation is very long and beyond a forum post. You could find it here:
That sounds great! I can use the Policy editor to restrict movements. I’ll give it a try and return to this thread if I have any questions. Thank you very much!
(I take it you mean malware inside of a qube (domU), because if there’s malware in dom0, it’s already game over.)
The answer is that explicit user action (in the form of granting permission from dom0) is required. That’s what prevents malware in the qube from using these commands to do anything. It doesn’t matter whether there’s passwordless root access in the qube. Unless the user approves the action from dom0 (either via manual prompt or RPC policy rule), the malicious qube won’t be able to maliciously affect anything outside of itself.
Yes, this issue was addressed through the architecture of Qubes OS itself from the very beginning. Qubes is designed to address this very problem. Passwordless root is irrelevant. Qubes OS doesn’t treat the Linux user/root distinction as a real security boundary, because it isn’t secure enough for Qubes’ use case. Qubes uses virtual machines as security boundaries instead.
Only with explicit user action in dom0.
Your questions seem to presuppose that a single compromised qube can exert full and arbitrary control over the entire system, but this is in fact the very thing that Qubes OS is engineered to prevent from happening. Stopping this very thing from happening is, in fact, the entire point of Qubes OS and the very reason for its existence.