[pve-devel] [PATCH qemu-server 1/7] api2 : migrate_vm : add migration_type "external"

[Alexandre DERUMIER]

>>@Alexandre: please set the permissions to root at pam only for this new API 
>>path. 

yes, sure.


>>I see the following problematic aspects otherwise: 
>>- potential back channel from a user/attacker-controlled target host to 
>>the source node via bugs in Qemu (might not even require a bug?) 
>>- enumeration of hosts that root at pam can automatically connect to 
>>- intrusion into node/cluster that root at pam can automatically connect to 
>>by live-migrating user/attacker-controlled VM there and trying to 
>>escape VM (e.g., the bridge/network there might have totally different 
>>assumptions about the trustworthiness of the attached guests, the 
>>node/cluster might not have the same patch level, etc.pp.) 



>>given the above, I am not sure whether a model with explicit public keys 
>>to target mapping somewhere in /etc/pve/priv/ might not be preferable 
>>even with a limitation to root at pam. 

Ok, I'll look at this.


----- Mail original -----
De: "Fabian Grünbichler" <f.gruenbichler at proxmox.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>
Cc: "aderumier" <aderumier at odiso.com>
Envoyé: Mercredi 14 Novembre 2018 11:37:16
Objet: Re: [pve-devel] [PATCH qemu-server 1/7] api2 : migrate_vm : add migration_type "external"

On Tue, Nov 13, 2018 at 11:22:23AM +0100, Dietmar Maurer wrote: 
> I would like to move forward with that, but changing an existing API makes that difficult. 
> 
> I would suggest to add a second API entry point instead: 
> 
> __PACKAGE__->register_method({ 
> name => 'external_migrate_vm', 
> path => '{vmid}/external_migrate', 
> method => 'POST', 
> ... 
> 
> Feel free to choose a better name ;-) We can the mark this API as unstable/experimental, and modify 
> the parameters/types. IMHO most existing parameters does not really makes sense with external migration. 
> I guess it is still possible to factor out most common code to avoid code duplication. 
> 
> What do you think? 

@Alexandre: please set the permissions to root at pam only for this new API 
path. 

I see the following problematic aspects otherwise: 
- potential back channel from a user/attacker-controlled target host to 
the source node via bugs in Qemu (might not even require a bug?) 
- enumeration of hosts that root at pam can automatically connect to 
- intrusion into node/cluster that root at pam can automatically connect to 
by live-migrating user/attacker-controlled VM there and trying to 
escape VM (e.g., the bridge/network there might have totally different 
assumptions about the trustworthiness of the attached guests, the 
node/cluster might not have the same patch level, etc.pp.) 

given the above, I am not sure whether a model with explicit public keys 
to target mapping somewhere in /etc/pve/priv/ might not be preferable 
even with a limitation to root at pam.