Bug 874728

Summary:	RFE: add special "all" secure channel that would make qemu listen just on tls-port and ignore the rest of channel settings
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	David Jaša <djasa>
Component:	ovirt-engine	Assignee:	Nobody's working on this, feel free to take it <nobody>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.1.0	CC:	acathrow, desktop-qa-list, iheim, jkt, lpeer, michal.skrivanek, oourfali, Rhev-m-bugs, uril, yeylon
Target Milestone:	---	Keywords:	FutureFeature, Improvement
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-08-05 09:47:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	819499
Bug Blocks:	879358

Description David Jaša 2012-11-08 18:08:38 UTC

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 05:47:44 UTC

oved, iirc you dablled in this area.
thoughts?

Comment 2 Oved Ourfali 2012-11-09 08:30:12 UTC

(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 08:32:42 UTC

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 09:21:04 UTC

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 20:16:40 UTC

(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 12:36:36 UTC

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 18:16:36 UTC

I agree that using only a single secure port makes sense.

Comment 8 Itamar Heim 2013-06-23 06:36:52 UTC

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 06:38:42 UTC

and:
Bug 879358 - RFE: overhaul spice secure/plain channel settings

Comment 10 David Jaša 2013-07-12 14:51:07 UTC

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 09:47:17 UTC

bug 879358 summarizes this one nicely, no need to track separately for now

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