En effet, les réponses sont toutes bonnes, c'est pour bosser facilement en développement. La sécurité peut parfois être un frein à l'avancement.
C'est bien agréable de savoir qu'on peut faire toutes les manips iptables que l'on veut sans perdre la connexion hyperviseur/invité lors de la mise au point.
Et si on a des tests sur une machine qui justement est très sécurisé au niveau ip, et que l'on veut virtualiser cette machine pour simuler des attaques ip, une entrée pour l'administration des tests par une des interfaces est une grave modification du système sous test.
On peut aussi mettre des droits d'exécution à root uniquement sur le binaire vsock_cli pour gérer la sécurité. Il faut avoir à l'esprit que l'on est déjà dans la machine hôte avant d'utiliser vsock. On peut ne lancer le serveur vsock_srv qu'avec droits utilisateur réduits ...
Bref, on peut quand même maitriser ce que l'on ouvre.
[^] # Re: Que veut dire exactement "la sécurité en moins" ?
Posté par clownix (site web personnel) . En réponse à la dépêche QEMU/KVM et les VirtioVsock. Évalué à 10.
En effet, les réponses sont toutes bonnes, c'est pour bosser facilement en développement. La sécurité peut parfois être un frein à l'avancement.
C'est bien agréable de savoir qu'on peut faire toutes les manips iptables que l'on veut sans perdre la connexion hyperviseur/invité lors de la mise au point.
Et si on a des tests sur une machine qui justement est très sécurisé au niveau ip, et que l'on veut virtualiser cette machine pour simuler des attaques ip, une entrée pour l'administration des tests par une des interfaces est une grave modification du système sous test.
On peut aussi mettre des droits d'exécution à root uniquement sur le binaire vsock_cli pour gérer la sécurité. Il faut avoir à l'esprit que l'on est déjà dans la machine hôte avant d'utiliser vsock. On peut ne lancer le serveur vsock_srv qu'avec droits utilisateur réduits ...
Bref, on peut quand même maitriser ce que l'on ouvre.