Feature: Don't let VM run while other specified VMs are running

[t4777sd]

It would be great if it was possible to prevent a VM from running if other select VMs are running. For example, a user could make it so their "personal" VM will not run as long as the "work" VM is running (and vice-versa).

This guarantees there is never any accidental cross-contamination between the two VMs from an errant copy / paste or even by accidently sending files from personal to the work VM as the send file would fail due to the inability to start the VM.

It also can be used to guarantee that the memory of one high security VM is not sniffed when a lower security VM is exploited due to all the new memory sniffing bugs. Keeping with the work / personal use-case described a person may be doing more risky things on the personal VM and do not want to compromise the work VM .

Qubes OS version:

4.0

[pgerber]

FYI, it's already possible to restrict between which VMs can be copied (clipboard and files). It's not as thorough a protection as preventing two VMs from running concurrently but it's a start.

Copy and Paste

To prevent accidental pasting, add something like this to the top of /etc/qubes-rpc/policy/qubes.ClipboardPaste in dom0:

personal   work        deny
work       personal    deny

The Copy and Paste between domains section in the documentation has some more details.

Copying Files

Similarly, you can prevent inter-VM copying by adding something like this at the top of /etc/qubes-rpc-policy/qubes.Filecopy in dom0:

personal  work        deny
work      personal    deny

[pgerber]

FYI, it's already possible to restrict between which VMs can be copied (clipboard and files). It's not as thorough a protection as preventing two VMs from running concurrently but it's a start.

Copy and Paste

To prevent accidental pasting, add something like this to the top of /etc/qubes-rpc/policy/qubes.ClipboardPaste in dom0:

personal   work        deny
work       personal    deny

The Copy and Paste between domains section in the documentation has some more details.

Copying Files

Similarly, you can prevent inter-VM copying by adding something like this at the top of /etc/qubes-rpc-policy/qubes.Filecopy in dom0:

personal  work        deny
work      personal    deny

[Aekez]

It also can be used to guarantee that the memory of one high security VM is not sniffed when a lower security VM is exploited due to all the new memory sniffing bugs.

I wonder if the differences of HVM and PVH virtualization modes would mean it is less of a concern on PVH mode VM's and a greater concern on say the sys-net or sys-usb, which is forced to run in HVM mode?

• Especially machines that doesn't have the hardware and is forced to run in the previous PV mode, and memory leak, as far as I remember reading, is definitely an issue on PV mode.
• So how well does PVH (and HVM) hold up against memory leak/attacks?

---

A more clear end-user awareness (i.e. via a doc) whether compromises in sys-net running in HVM mode is a concern for memory management of a PVH mode VM which is working online with sensitive information; in contrast to a PVH VM which works offline with sensitive information despite HVM mode sys-net also running at the same time, but the PVH VM being isolated.

• For example, can the end-user feel safe using HVM sys-net, if simultaneously working in an isolated offline PVH VM. Questions like these might be worth answering, i.e. in a light-read doc?
• As such, the idea here is a doc with TL:DR for users who might risk skipping if the text/doc is too long / too detailed, and then instead put in various links here and there in the doc to longer reads for those who are interested in the greater details and security understanding of the various details briefly mentioned in the TL:DR doc.

---

Also is there any known/planned improved PVH (supporting pass-through if possible) or other better approaches on the horizont to the current modes, i.e. in Qubes 4.1. or maybe Qubes 5.0+?

[Aekez]

It also can be used to guarantee that the memory of one high security VM is not sniffed when a lower security VM is exploited due to all the new memory sniffing bugs.

I wonder if the differences of HVM and PVH virtualization modes would mean it is less of a concern on PVH mode VM's and a greater concern on say the sys-net or sys-usb, which is forced to run in HVM mode?

• Especially machines that doesn't have the hardware and is forced to run in the previous PV mode, and memory leak, as far as I remember reading, is definitely an issue on PV mode.
• So how well does PVH (and HVM) hold up against memory leak/attacks?

---

A more clear end-user awareness (i.e. via a doc) whether compromises in sys-net running in HVM mode is a concern for memory management of a PVH mode VM which is working online with sensitive information; in contrast to a PVH VM which works offline with sensitive information despite HVM mode sys-net also running at the same time, but the PVH VM being isolated.

• For example, can the end-user feel safe using HVM sys-net, if simultaneously working in an isolated offline PVH VM. Questions like these might be worth answering, i.e. in a light-read doc?
• As such, the idea here is a doc with TL:DR for users who might risk skipping if the text/doc is too long / too detailed, and then instead put in various links here and there in the doc to longer reads for those who are interested in the greater details and security understanding of the various details briefly mentioned in the TL:DR doc.

---

Also is there any known/planned improved PVH (supporting pass-through if possible) or other better approaches on the horizont to the current modes, i.e. in Qubes 4.1. or maybe Qubes 5.0+?