Inconsistency between policies and VMs

[svenssonaxel]

Qubes OS version: R3.2

---

Steps to reproduce the behavior:

1. Open a new dispVM, e.g. disp1
2. Execute qvm-copy-to-vm othervm file
3. A confirmation question pops up. Click "Yes to all" on the question.
4. In /etc/qubes-rpc/policy/qubes.Filecopy, a policy is created as "disp1 othervm allow".
5. Restart Qubes OS
6. Open a new dispVM with the same name as before, e.g. disp1
7. Repeat step 2

Expected behavior:

8. A confirmation question pops up.

Actual behavior:

8. Without any confirmation, the file is copied.

General notes:

This behavior might not seem very strange to those who understand the implementation of policies, and it is understandable that policies reside in their own folder, seeing that they do not belong to any one VM and cannot easily be located inside a VM directory.

However, the behavior should fulfill the expectation that disposable VMs do not leave a lasting effect on the system.
In particular, this creates an unexpected security-critical relationship that affects a completely unrelated machine, i.e. the dispVM "disp1" after restart.

On a related note, something similar can be achieved by renaming VMs:

1. Create a policy allowing vm1 to send files to vm2.
2. Rename vm1 to temp-name.
3. Rename vm2 to vm1.
4. Rename temp-name to vm2.
   Expected:
5. vm2 can send files to vm1.
   Actual:
6. vm1 can send files to vm2.

Again, the current behavior might be expected for those who understands the implementation, but it runs counter to the concepts involved.

---

Related issues:

[unman]

It's not the disposable VM that has left a lasting effect on the system. It's your decision to click "Yes to All" for a disposable VM, which seems a bad idea to me, and perhaps should not be allowed without a warning or at all.
Given the recycling of dispX names, it's a subset of your "related note".
I can see two solutions:

1. Throw advisory message on renaming of qube, suggesting user reviews policies.
2. Automatically parse the policy files renaming entries to match the rename.

and perhaps
3. When qube is removed, automatically remove all relevant entries from the policy files.

[unman]

It's not the disposable VM that has left a lasting effect on the system. It's your decision to click "Yes to All" for a disposable VM, which seems a bad idea to me, and perhaps should not be allowed without a warning or at all.
Given the recycling of dispX names, it's a subset of your "related note".
I can see two solutions:

1. Throw advisory message on renaming of qube, suggesting user reviews policies.
2. Automatically parse the policy files renaming entries to match the rename.

and perhaps
3. When qube is removed, automatically remove all relevant entries from the policy files.

[andrewdavidwong]

I think this sort of thing is exactly why the devs chose to make VM names immutable in 4.0. I'm not sure whether there's anything actionable in this issue, since this has already been addressed in 4.0. Leaving it up to @marmarek to decide.

[andrewdavidwong]

I think this sort of thing is exactly why the devs chose to make VM names immutable in 4.0. I'm not sure whether there's anything actionable in this issue, since this has already been addressed in 4.0. Leaving it up to @marmarek to decide.

[unman]

I dont think it should be too hard to implement any of the options I proposed, and since it's an issue in the stable release I think it should be fixed.
I'd favour 2 and 3 rather than just producing a warning.

[unman]

I dont think it should be too hard to implement any of the options I proposed, and since it's an issue in the stable release I think it should be fixed.
I'd favour 2 and 3 rather than just producing a warning.

[unman]

On the other hand, it would ease transition to 4.0 if we removed the ability to rename in 3.2.
That would then leave 3 to handle qube removal (including end of disposableVM).

[unman]

On the other hand, it would ease transition to 4.0 if we removed the ability to rename in 3.2.
That would then leave 3 to handle qube removal (including end of disposableVM).

[unman]

scratch my last comment because 4.0 does have qvm-rename, and will (I think) be open to the same issue, which suggests 2 and 3 as the solution.

[unman]

scratch my last comment because 4.0 does have qvm-rename, and will (I think) be open to the same issue, which suggests 2 and 3 as the solution.