Bug 874728 - RFE: add special "all" secure channel that would make qemu listen just on tls-port and ignore the rest of channel settings
RFE: add special "all" secure channel that would make qemu listen just on tls...
Status: CLOSED DUPLICATE of bug 879358
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
virt
: FutureFeature, Improvement
Depends On: 819499
Blocks: 879358
  Show dependency treegraph
 
Reported: 2012-11-08 13:08 EST by David Jaša
Modified: 2013-08-05 05:47 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-05 05:47:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-11-08 13:08:38 EST
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):
3.1

How reproducible:
always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Itamar Heim 2012-11-09 00:47:44 EST
oved, iirc you dablled in this area.
thoughts?
Comment 2 Oved Ourfali 2012-11-09 03:30:12 EST
(In reply to comment #1)
> oved, iirc you dablled in this area.
> thoughts?

Yes.
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).
Comment 3 Oved Ourfali 2012-11-09 03:32:42 EST
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).
Comment 4 Uri Lublin 2012-11-11 04:21:04 EST
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".
Comment 5 Itamar Heim 2012-11-11 15:16:40 EST
(In reply to comment #4)
> 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".

how do we know/check that the client knows to decipher what 'all' means?
Comment 6 David Jaša 2012-11-12 07:36:36 EST
Oved,
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.
Comment 7 Uri Lublin 2012-11-12 13:16:36 EST
I agree that using only a single secure port makes sense.
Comment 8 Itamar Heim 2013-06-23 02:36:52 EDT
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"
Comment 9 Itamar Heim 2013-06-23 02:38:42 EDT
and:
Bug 879358 - RFE: overhaul spice secure/plain channel settings
Comment 10 David Jaša 2013-07-12 10:51:07 EDT
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".
Comment 11 Michal Skrivanek 2013-08-05 05:47:17 EDT
bug 879358 summarizes this one nicely, no need to track separately for now

*** This bug has been marked as a duplicate of bug 879358 ***

Note You need to log in before you can comment on or make changes to this bug.