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: 11
- Last updated: (DATE)
- Percentage of completion: 75%
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 [IN PROGRESS] http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00826.html
- [SERVER] Encourage QEMU to produce a new release in time for Fedora 11, or backport the accepted patches to QEMU 0.9.1 [IN PROGRESS] ETA: March 1
- [MANAGEMENT] Extend libvirt to allow configuration of SASL authentication for QEMU [NOT STARTED]
- [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
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
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 :)
Release Notes
TBD