Virtualization VNC Authentication
Summary
Define a mapping of SASL authentication into the VNC protocol, and implement it for QEMU and GTK-VNC, providing strongly authenticated, securely encrypted remote access of virtual guest consoles.
Owner
- Name: Daniel Berrange
- email: berrange@fedoraproject.org
Current status
- Targeted release: Fedora 11
- Last updated: 2009-03-09
- Percentage of completion: 100%
Detailed Description
The Fedora 8 release introduced the new feature VirtSecurity which comprised supporting the SSL/TLS protocol and x590 certificate in the libvirt RPC layer and VNC protocol. The Fedora 9 release extended this work to add the new feature SASL authentication to the libvirt RPC layer. The next logical piece in the security puzzle for virtualization is thus SASL authentication in the VNC protocol. That is the purpose of this new feature for Fedora 11.
VNC has been lacking in serious authentication capabilities since the day it was invented. Various projects have invented new authentication types eg, UltraVNC's MS-Logon integration, but no one has ever attempted to define an portable & extensible standard for VNC authentication that can easily be used across any client/server implementation.
The SASL protocol is well documented Internet specification (RF 4422) that has multiple implementations (cyrus-sasl, gsasl, Java SASL) portable to every major operating system. It defines a protocol that is independent of the authentication mechanism, so as new mechanisms are invented/implemented they can be plugged into existing SASL enabled applications without needing further code / protocol changes.
Of particular interest is the GSSAPI mechanism, which enables Kerberos single-sign-on. Other mechanisms include plain username/password (checkable against files, LDAP, SQL database, etc), one-time passwords, and more).
Benefit to Fedora
A number of virtualization platforms use QEMU for their host device model, and the primary protocol for interacting with QEMU remotely is VNC. Until now the only truly secure means of accessing VNC remotely is to tunnel the VNC connection over SSH. This is not a satisfactory approach for many virtualization hosts, since it entails opening SSH access to the virtualization for guest administrators. Supporting SASL in the VNC protocol, in concert with the previously added SSL/TLS feature, will allow strongly authenticated, securely encrypted remote access to VNC server without any need for tunnelling.
With a little extra effort, the work to support VNC+SASL in the virtualization arena, can be extended to desktop users, by adding SASL to the VINO remote desktop service in GNOME. This will provide Fedora users with a strongly authenticated, securely encrypted remote desktop service.
Scope
- [SPEC] Obtain an officially allocated VNC security type code for the new SASL protocol [DONE]
- [SPEC] Write a specification for mapping SASL into the VNC protocol [DONE]
- [SERVER] Implement the core SASL protocol in QEMU's VNC server [DONE]
- [SERVER] Implement a means to define the user ACL for authentication in QEMU [DONE]
- [SERVER] Get code reviewed & accepted in upstream QEMU [DONE]
- [SERVER] Encourage QEMU to produce a new release in time for Fedora 11, or backport the accepted patches to QEMU 0.9.1 [DONE]
- [MANAGEMENT] Extend libvirt to allow configuration of SASL authentication for QEMU [DONE]
- [CLIENT] Implement the core SASL protocol in GTK-VNC client [SENT UPSTREAM] http://sourceforge.net/mailarchive/forum.php?thread_name=20090204173459.GK26946%40redhat.com&forum_name=gtk-vnc-devel
All present in Fedora, including GTK-VNC patches
How To Test
SASL supports a number of pluggable authentication mechanisms. Some mechanisms (GSSAPI, DIGEST-MD5) provide session data encryption, while others rely on security of the underlying data channel, thus requiring use of TLS/x509 to be secure
Recommended testing auth configurations
FESCo requested more information for this section on 2009-02-27
Plain TCP + GSSAPI. Aka Kerberos single-sign-on
The GSSAPI mechanism provides data encryption as well as authentication, thus does not require use of TLS. To test this requires a Kerberos server. Fedora includes the FreeIPA server which is easy to deploy and manage.
TBD: Fill in how to configure & test this
Plain TCP + Digest-MD5
The SASL DIGEST-MD5 auth mechanism is considered to no longer provide satisfactory security, but it is easy to setup without needing TLS, so is a useful way to test the core infrastructure in apps, even if not suitable for production deployment
TBD: Fill in how to configure & test this
SSL/TLS + Plain
A simple password based authentication mechanism, requiring that the server use TLS for encryption
TBD: Fill in how to configure & test this
User Experience
In a site which has Kerberos/FreeIPA deployed, users will be able to configure their virtual guests to use SASL authentication with GSSAPI. Using client tools such as virt-viewer, virt-manager or vinagre they will be able to access their guest virtual machine desktops using Kerberos Single-sign-on, avoiding any need for passwords.
In a site without Kerberos, users will be able to cofnigure their virtual guests with TLS + x590 certificates, and then authenticate with passwords. The virt-viewer/manager/vinagre client will store their passwords in the GNOME keyring, so after the initial connection, all subsequent connections will be passwordless
The user will never have to setup SSH tunnels for accessing VNC servers again.
Dependencies
This work is spread across a number of packages
- qemu, kvm - gtk-vnc
Contingency Plan
No existing functionality is impacted, so in event of problems this feature will be postponed to a later Fedora release and users will continue with their current deployment / remote access methods.
Documentation
TBD: Link to the VNC SASL security specification. Written, but needs permanent home website http://realvnc.com/pipermail/vnc-list/2008-December/059462.html TBD: Link to the QEMU documentation on configuring SASL (to be written :-) TBD: Link to the libvirt documentation on configuring SASL for VNC (to be written :)
Running QEMU/KVM standalone, with SASL enabled.
Add the ',sasl' flag when launching QEMU with a VNC server
If using GSSAPI SASL mechanism, then jjust add the 'sasl' flag eg
qemu ... -vnc localhost:1,sasl
If not using GSSAPI, then first configure TLS (http://bellard.org/qemu/qemu-doc.html#SEC36) and then add the 'sasl' flag eg
qemu ... -vnc localhost:1,tls,x509,sasl
The choice of SASL mechanism is made in /etc/sasl2/qemu.conf. "gssapi" enables Kerberos, while "digest-md5" is a simple (but not very secure) username+ password method
Running QEMU from libvirt
Edit /etc/libvirt/qemu.conf and set
vnc_sasl = 1
And to override use of /etc/sasl2/qemu.conf, can also set
vnc_sasl_dir = /some/directory
Release Notes
Fedora 11 introduces the ability to use the SASL protocol for authenticating VNC connection to KVM and QEMU virtual machines. SASL is a pluggable system, allowing many different authentication mechanisms to be configured without changing the application code. The use of SASL, in combination with existing TLS encryption support, will allow clients like vinagre, virt-viewer and virt-manager to securely connect to remote virtual machine consoles hosted on Fedora servers. In environments where Kerberos is deployed, this further allows for secure single sign on to the VNC server. This new authentication capability obsoletes the traditional VNC password scheme which is not sufficiently secure.