Owner

Current status

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.

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.

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 (and maybe 'xen')
- gtk-vnc
- Possibly vino

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 :)

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.