Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1602418

Summary:	VNC TLS config must support use of encrypted TLS private keys
Product:	Red Hat Enterprise Linux Advanced Virtualization	Reporter:	Daniel Berrangé <berrange>
Component:	libvirt	Assignee:	Ján Tomko <jtomko>
Status:	CLOSED ERRATA	QA Contact:	yafu <yafu>
Severity:	high	Docs Contact:
Priority:	medium
Version:	8.0	CC:	fjin, hpopal, jdenemar, jsuchane, knoel, mtessun, xuzhang, yafu
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	8.1	Flags:	rule-engine: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-5.3.0-1.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-11-06 07:11:37 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Daniel Berrangé 2018-07-18 10:37:29 UTC

Description of problem:
The modern TLS credentials config in QEMU supports used of encrypted TLS keys. Libvirt supports this for migration/chardevs using the -object syntax, but does not yet support it for VNC.

This will cause a problem if /etc/libvirt/qemu.conf sets a default_tls_x509_cert_dir to point to a set of encrypted x509 creds, and the user has not set different creds with vnc_tls_x509_cert_dir.

We must fix that problem with use of default_tls_x509_cert_dir for VNC, and also allow vnc_tls_x509_secret_uuid parameter to be used.

Version-Release number of selected component (if applicable):
4.5.0-1.el8

Comment 8 Ján Tomko 2019-01-16 07:42:33 UTC

Proposed upstream patches:
https://www.redhat.com/archives/libvir-list/2019-January/msg00490.html

Comment 9 Ján Tomko 2019-01-21 12:59:50 UTC

v2:
https://www.redhat.com/archives/libvir-list/2019-January/msg00689.html

Comment 10 Ján Tomko 2019-01-22 11:51:18 UTC

Pushed as:
commit 2e2b0d69a99e9f985796f8399fdc8f2253a53e59
Author:     Ján Tomko <jtomko>
CommitDate: 2019-01-22 12:18:28 +0100

    qemu: add support for encrypted VNC TLS keys
    
    Use the password stored in the secret driver under
    the uuid specified by the vnc_tls_x509_secret_uuid
    option in qemu.conf.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1602418
    
    Signed-off-by: Ján Tomko <jtomko>
    Reviewed-by: John Ferlan <jferlan>

git describe: v5.0.0-80-g2e2b0d69a9

Comment 14 yafu 2019-07-19 06:15:18 UTC

Verified with libvirt-5.5.0-1.el8.x86_64.

Test steps:
1.Define a secret:
# cat tls-secret.xml 
<secret ephemeral='no' private='yes'>
   <description>sample tls secret</description>
   <usage type='tls'>
      <name>TLS_example</name>
   </usage>
</secret>
#virsh define secret.xml
#virsh secret-list
# virsh secret-list
 UUID                                   Usage
---------------------------------------------------------
 32526718-87f7-47a8-ac13-bf48cc639aa0   tls TLS_example

2.Set a value to the secret:
# MYSECRET=`printf %s "redhat" | base64`
#virsh secret-set-value 32526718-87f7-47a8-ac13-bf48cc639aa0 $MYSECRET
Secret value set

3.Set vnc secret ane enable vnc_tls in qemu.conf and restart libvirtd service:
#vim /etc/libvirt/qemu.conf
vnc_tls =1 
vnc_tls_x509_secret_uuid = "32526718-87f7-47a8-ac13-bf48cc639aa0"
#systemctl restart libvirtd

4.set up vnc tls env;

5.Start a guest with vnc graphical device:
#virsh dumpxml vm2 | grep -i vnc
 <graphics type='vnc' port='5901' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

6.Check the qemu cmd line:
#ps aux | grep -i passwordid
...-object tls-creds-x509,id=vnc-tls-creds0,dir=/etc/pki/libvirt-vnc,endpoint=server,verify-peer=no,passwordid=vnc-tls-creds0-secret0 -vnc 0.0.0.0:1,tls-creds=vnc-tls-creds0...

7.Connect guest by vncviewer
# vncviewer  $hostname_or_ip:5901  -X509CA /etc/pki/libvirt-vnc/ca-cert.pem
Click on 'yes' in popped vncviewer window to continue, can connect guest successfully.

8.Also check there are no memory leak while starting/destroying guest when vnc tls secret enabled.

Comment 15 yafu 2019-07-22 03:41:31 UTC

Also test setting a non-exist secret uuid in the qemu.conf, can get expected error info.
Test steps:
1.Set a non-exist and malformed secret uuid in the qemu.conf and restart libvirtd:
#vim /etc/libvirt/qemu.conf
vnc_tls =1 
vnc_tls_x509_secret_uuid = "1111-1111"
#systemctl restart libvirtd

2.Start a guest with vnc graphical device:
# virsh start vm2
error: Failed to start domain vm2
error: unsupported configuration: malformed TLS secret uuid '1111-1111' provided

3.Set a non-exist secret uuid in the qemu.conf and restart libvirtd:
#virsh secret-list
 UUID                                   Usage
---------------------------------------------------------
 32526718-87f7-47a8-ac13-bf48cc639aa0   tls TLS_example

#vim /etc/libvirt/qemu.conf
vnc_tls =1 
vnc_tls_x509_secret_uuid = "32526718-87f7-47a8-ac13-bf48cc639aaa"
#systemctl restart libvirtd

4.Start a guest with vnc graphical device:
# virsh start vm2
error: Failed to start domain vm2
error: Secret not found: no secret with matching uuid '32526718-87f7-47a8-ac13-bf48cc639aaa'

Comment 17 errata-xmlrpc 2019-11-06 07:11:37 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3723