Do not allow to rename VMs directly

[marmarek]

In Qubes 4.0 we want to forbid changing VM name property. This is mostly because VM name is used in Qubes RPC policy as identifier, so renaming VM can have severe security consequences. This is especially important when such operation could be performed by semi-trusted Management VM (through Admin API).

In practice changing VM name will still be possible, in two steps:

1. Clone VM under new name (thanks to LVM, this operation is fast)
2. Remove old VM

[jpouellet]

Are the initial and final system states as a result of "rename" vs. "clone & remove" different? How?

Are mgmt/admin VMs somehow restricted from performing the latter?

I believe I understand the underlying security motivation, but I do not see what is gained by only disallowing vm name change while clone & rm is still possible.

[jpouellet]

Are the initial and final system states as a result of "rename" vs. "clone & remove" different? How?

Are mgmt/admin VMs somehow restricted from performing the latter?

I believe I understand the underlying security motivation, but I do not see what is gained by only disallowing vm name change while clone & rm is still possible.

[marmarek]

Yes, Mgmt VM needs permission to manage both "old" and "new" VMs. If it's limited only to set few properties, it can't perform full clone. For example if you don't allow it to add new tags to a VM, the new VM will not have those tags set (it's up to Mgmt VM what to do - either ignore the error, or abort operation).
As of security aspect - this is mostly because we use VM names to reference VMs - for example in qrexec policy, in created-by-* tag etc. If you consider VM rename, those things can easily end out of sync - so in many cases you'd block VM rename anyway.

Also, renaming VM have a lot of corner cases (technically-wise) - for example tracking VM rename over Admin API is tricky. New VM have new UUID, so it's easy to detect remove & create.
Even in personal system (with user having full control) this is sometimes tricky - like application menu being out of sync, or Qubes Manger not noticing renamed VM.

[marmarek]

Yes, Mgmt VM needs permission to manage both "old" and "new" VMs. If it's limited only to set few properties, it can't perform full clone. For example if you don't allow it to add new tags to a VM, the new VM will not have those tags set (it's up to Mgmt VM what to do - either ignore the error, or abort operation).
As of security aspect - this is mostly because we use VM names to reference VMs - for example in qrexec policy, in created-by-* tag etc. If you consider VM rename, those things can easily end out of sync - so in many cases you'd block VM rename anyway.

Also, renaming VM have a lot of corner cases (technically-wise) - for example tracking VM rename over Admin API is tricky. New VM have new UUID, so it's easy to detect remove & create.
Even in personal system (with user having full control) this is sometimes tricky - like application menu being out of sync, or Qubes Manger not noticing renamed VM.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.1-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.1-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update