RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 882336 - ask libvirt for spice CA cert and host subject of server-cert and pass it to spice-gtk if virt-viewer <--> libvirt connection is secure
Summary: ask libvirt for spice CA cert and host subject of server-cert and pass it to ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: beta
: 6.5
Assignee: Virt Viewer Maint
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 882329
Blocks: 921394
TreeView+ depends on / blocked
 
Reported: 2012-11-30 17:24 UTC by David Jaša
Modified: 2014-03-10 11:35 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 921394 (view as bug list)
Environment:
Last Closed: 2014-03-10 11:35:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description David Jaša 2012-11-30 17:24:31 UTC
Description of problem:
Currently, virt-viewer in virt-viewer mode requires to specify --spice-ca-file and --spice-host-subject options. These are beneficial to require when connecting to insecure libvirt URI (remote uri with tcp transport or if we nanny the user, ext transport as well) but when connecting over unix, tls, ssh or libssh2 transports, these informations can be fetched in a secure way without need to bug the user about them.

spice-gtk accepts CA file currently as a file only but there is proposal for it to be able to accept it via file that seems simple enough to be accepted quite soon so I'm making this depend on that bug (bug 882329) so that we do this right(TM) from the beginning.

Version-Release number of selected component (if applicable):
virt-viewer-0.5.2-16.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. if not already set up this way
create spice keys/certificates and configure qemu.conf to enable spice_tls and point it to directory with certs/keys
2. create a domain that will require tls connection on spice main channel:
domain xml:
<?xml version="1.0"?>
<domain type="kvm">
  <name>tls-main</name>
  <memory>32768</memory>
  <os>
    <type arch="x86_64" machine="pc">hvm</type>
  </os>
  <devices>
    <graphics type="spice" autoport="yes" >
      <channel name="main" mode="secure" />
    </graphics>
    <video>
      <model type="qxl" vram="32768" heads="1"/>
    </video>
  </devices>
</domain>

create the ephemeral domain:
virsh [-c LIBVIRT_URI] create PATH_TO_XML

3. open the domain console using any transport but tcp (just qemu:///system is fine for example):
virt-viewer --spice-debug -c LIBVIRT_URI tls-main
  
Actual results:
virt-viewer doesn't connect and its output contains these lines:

(virt-viewer:24275): GSpice-DEBUG: spice-session.c:1617 Trying one socket
(virt-viewer:24275): GSpice-DEBUG: spice-session.c:1566 main-1:0: Socket pending
(virt-viewer:24275): GSpice-DEBUG: spice-session.c:1581 main-1:0: Finally connected
(virt-viewer:24275): GSpice-DEBUG: spice-channel.c:1160 main-1:0: channel type 1 id 0 num common caps 1 num caps 1
(virt-viewer:24275): GSpice-DEBUG: spice-channel.c:1182 main-1:0: Peer version: 2:2
(virt-viewer:24275): GSpice-DEBUG: spice-channel.c:1666 main-1:0: switching to tls
(virt-viewer:24275): GSpice-DEBUG: spice-channel.c:2040 main-1:0: channel has error, breaking loop
(virt-viewer:24275): GSpice-DEBUG: spice-channel.c:2255 main-1:0: Open coroutine starting 0x943fa0
(virt-viewer:24275): GSpice-DEBUG: spice-channel.c:2098 main-1:0: Started background coroutine 0x944028
(virt-viewer:24275): GSpice-DEBUG: spice-session.c:1604 Resolving host localhost 5901
(virt-viewer:24275): GSpice-DEBUG: spice-session.c:1617 Trying one socket
(virt-viewer:24275): GSpice-DEBUG: spice-session.c:1566 main-1:0: Socket pending
(virt-viewer:24275): GSpice-DEBUG: spice-session.c:1581 main-1:0: Finally connected
(virt-viewer:24275): GSpice-DEBUG: spice-channel.c:2148 main-1:0: CA file: /home/david/.spicec/spice_truststore.pem

note that ${HOME}/.spicec/spice_truststore.pem is fallback path when no CA file is given to spice-gtk


Expected results:
virt-viewer connects just fine

Additional info:

Comment 2 Marc-Andre Lureau 2014-03-07 18:04:43 UTC
That's going to be tricky, not sure it is all worth it..

Daniel, can we imagine an API to query the driver config file, read values? and read external files? (ouch)

or maybe some of those config values should be moved to the domain XML/API?

Comment 3 Daniel Berrangé 2014-03-10 09:50:13 UTC
I'm not really convinced this is a worthwhile RFE. In small scale deployments I think most people will just use SSH tunnelling for libvirt. For medium-to-large scale deployments which choose to use TLS/x509, they are better off using a proper certificate management system to distribute their certs across all hosts.


In a pure TLS environment, even with this RFE, the admin will still need to setup certs for the libvirt client itself, so I don't see that setting up certs for SPICE at the same time is any larger burden. I don't see that a mixed auth environment (ssh for libvirt, tls for SPICE) is really a big enough use case to worry about.

Comment 4 Marc-Andre Lureau 2014-03-10 11:35:53 UTC
closing, for practical and technical reasons.


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