Red Hat Bugzilla – Bug 874728
RFE: add special "all" secure channel that would make qemu listen just on tls-port and ignore the rest of channel settings
Last modified: 2013-08-05 05:47:17 EDT
Description of problem:
add special "all" secure channel that would make qemu listen just on tls-port and ignore the rest of channel settings.
From 3.1 on, RHEV moves to use of all channels secured by default and this gives an opportunity to simplify some flows and save listening ports on the qemu.
Based on my knowledge, qemu and libvirt are ready for such a move and the only thing needed on VDSM side is to omit port= attribute of graphics element of libvirt domain xml and all its channel subelements. On frontend side, you can stop sending all the secure-channels-related info to the plugin/client.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
oved, iirc you dablled in this area.
(In reply to comment #1)
> oved, iirc you dablled in this area.
It requires changes in the UserPortal, the engine, and VDSM.
In the UserPortal we need to check with the spice guys what's the flag we need to pass (it is "default" iirc), and in VDSM we need to make a special treatment for it, as "all" is not a channel name for libvirt, but a special option.
Added dependency on 819499 (it was already closed, but contains useful information for this bug).
Uri - what should we do on the spice side in order to make it work with secured mode, instead of passing all the channels (I know that we already discussed it before, but it was a while ago).
The following should work (not tested):
Host side: vdsm/libvirt starts qemu-kvm with spice option "tls-channel=default"
Client side: RHEV-M portal sets secure-channels to "all".
(In reply to comment #4)
> The following should work (not tested):
> Host side: vdsm/libvirt starts qemu-kvm with spice option
> Client side: RHEV-M portal sets secure-channels to "all".
how do we know/check that the client knows to decipher what 'all' means?
If you don't set unsecured port on the spice-server, all channels will be secured no matter how you set the rest of the options (apart from options forcing unsecured channels that would make connection fail).
Given this, you can both SecureChannels and Port on client side and define secure-only connection just by passing HostIP, SecurePort, HostSubject and TrustStore.
Itamar, all spicec versions dating back to qspice times do know what "all" means. Spice-gtk-based clients do not recognize this option at all and ignore it - so what isn't enforced to be encrypted by the server (or hardcoded to prefer encryption: main and inputs), that will go over network in plaintext.
I agree that using only a single secure port makes sense.
michael - thoughts if should be merged with
Bug 803666 - Update format of SpiceSecureChannels to "channel" from "schannel"
Bug 975440 - Update format of SpiceSecureChannels to "channel" from "schannel"
Bug 879358 - RFE: overhaul spice secure/plain channel settings
Note how libvirt implements the default channel security setting:
The defaultMode attribute sets the default channel security policy, valid values are secure, insecure and the default any (which is secure if possible, but falls back to insecure rather than erroring out if no secure path is available). "defaultMode" since 0.9.12.
actual configuration schema in RHEV could mirror libvirts schema of defaultMode + <channel name="actual_channel" mode="mode"/> rather than use spice-server configuration schema with meta-channel "default".
bug 879358 summarizes this one nicely, no need to track separately for now
*** This bug has been marked as a duplicate of bug 879358 ***