Since the release of kvm-85, new support for vnc access lists and various authentication mechanisms have been added. In this article, I will show some example usage so that you can start using these features. These examples will be demonstrated using standalone kvm as opposed to running kvm from a GUI such as virt-manager. We'll look at sasl authentication then add vnc access lists on top of this.
In order to use the authentication mechanisms with kvm, the first thing you need to do is install some required development libraries. To check if you these are already installed on your system, run the configure command. As an example, if you don't have sasl devel libraries installed, you'll get the following output from your configure run.
SDL support yes
SDL static link yes
curses support no
mingw32 support no
Audio drivers oss
Extra audio cards ac97 es1370 sb16
Mixer emulation no
VNC TLS support no
VNC SASL support no
kqemu support no
kvm support yes
CPU emulation yes
brlapi support no
Documentation noOn fedora, you can install the required packages by issuing the commands
yum install cyrus-sasl-devel yum install gnutls-devel
If you're using ubuntu, you can use the apt-get to install the cyrus-sasl-devel libraries. The configure script will then probe for SASL and automatically enable it if found unless you run configure with the –disable-vnc-sasl to override it.
After installing cyrus-sasl-devel and gnutls-devel you can expect to get the following output after your configure run.
SDL static link yes
curses support no
mingw32 support no
Audio drivers oss
Extra audio cards ac97 es1370 sb16
Mixer emulation no
VNC TLS support yes
TLS CFLAGS
TLS LIBS -lgnutls
VNC SASL support yes
SASL CFLAGS
SASL LIBS -lsasl2
kqemu support no
kvm support yes
CPU emulation yes
brlapi support noBy default the qemu-kvm vnc sasl server will look at default locations for your qemu.conf file. For cyrus-sasl, this will typically be located either /etc/sasl2/ or /usr/lib/sasl2. Create your configuration file called qemu.conf specifying the location of the user database and authentication mechanism. For this example, I'll be using digest-md5 password authentication and /etc/sasl2/qemu.db for the user database file. Below shows the content of my qemu.conf file.
$ cat /etc/sasl2/qemu.conf mech_list: digest-md5 sasldb_path: /etc/sasl2/qemu.db
Next create a username password entry into this database with the following command.
$ saslpasswd2 -f /etc/sasl2/qemu.db hsolomon Password: Again (for verification):
To delete a user from your sasl password database, issue the following command.
$ saslpasswd2 -f /etc/sasl2/qemu.db -d hsolomon
To verify you can list entries in the username database with the following command.
$ sasldblistusers2 -f /etc/sasl2/qemu.db hsolomon@localhost.localdomain: userPassword
Note that the passwords are not listed but instead shown as “userPassword” for security reasons.
One thing to note is that not all vnc clients support the sasl protocol extensions. Examples of common vnc clients which do NOT support these extensions are RealVNC, UltraVNC and tightVNC. Conversely, the vnc clients which provide support for SASL protocol extensions include vinagre, virt-viewer and virt-manager. For this example, we'll use vinagre as the vnc client since we are testing with standalone kvm. I used vinagre version 2.26.1 from Fedora 11 as the current Fedora 10 version (2.24) does not support sasl. Below shows a snapshot of the login screen from vinagre.
Start kvm using the sasl option as shown below to enable sasl authentication
qemu-kvm -hda windows.img -m 500 -vnc :1,sasl ...
Now connect using your vinagre vnc client

By default, the vnc server will not enforce any ACL for access unless specified using the acl flag during startup. The following is an example of using the acl flag when starting your qemu instance.
qemu-kvm -hda windows.img -m 600 -vnc localhost:1,sasl,acl
The default policy of the acl is to block all vnc users from accessing the vnc server as shown below. If you try to connect using vnc at this point, you will be denied.
(qemu) acl show vnc.username policy: deny
For this example I need to connect to the qemu monitor and allow the user hsolomon access to the vnc server. Connect to your monitor and issue the following commands to setup your access list. In your case, specify your username that was setup using sasl as shown above.
(qemu) acl allow vnc.username hsolomon acl: added rule at position 1
and we verify this with the following command
(qemu) acl show vnc.username policy: deny 1: allow hsolomon
Now your access list will allow the specified user to log in with your vnc client.
Comments
Windows client
Monday, May 18, 2009 - 08:02 Radek Hladik (not verified)This looks very promising and I hope the ACLs will get to libvirt soon. However is there any client for Windows with SASL and SSL/TLS? The best option I've found so far is ssvnc ( http://www.karlrunge.com/x11vnc/ssvnc.html) however it does only TLS, not SASL.
And is it possible to make ACLs deciding on name from X509 certificate? It would be very helpful too.
Re: Windows Client
Monday, May 18, 2009 - 12:13 Haydn SolomonRadek,
I don't know about any other windows vnc clients with SASL auth support. I'll have to look into it and will check out your link. However, kvm also now supports tls as well so that the windows client you mentioned will work. I should have mentioned this in the post but I'll probably write another post on configuring this. Also libvirt does in fact support SASL auth for vnc server since version 0.6.1 and also tls. I'll write up some more on these procedures.
Windows client
Monday, May 18, 2009 - 12:49 Radek Hladik (not verified)I was wondering if it is possible to build gtk-vnc for windows but I could not find any info/documentation about it.
I know that libvirt supports TLS now however it can only specify which certificates can connect to the daemon, not per VM. I would like to be able to limit the connections per VM and I need windows client...
Now I see two promising but not yet usable options:
*username/password+TLS+kvm username ACL
*certificate+TLS+kvm certificate ACL.
Radek
btw: Tnak you for your great blog
Re: Windows client
Monday, May 18, 2009 - 13:07 Haydn SolomonRadek,
I don't know if you're aware of this but actually you can now start your kvm with a command line the following.
This is also a new feature since kvm-85 and I think this is what you might be looking for. I was planning writing up on this usage as well, it being a more secure configuration.
VMware ESX 3.5 includes
Monday, March 22, 2010 - 03:44 Spielautomatenführer (not verified)VMware ESX 3.5 includes support for operating system kernels that use Virtual Machine Interface (VMI). VMI is the VMware open paravirtualization interface and is included in Linux kernel version 2.6.22 and later. To use VMI, it must be enabled in your Linux kernel and for the ESX 3.5 virtual machine in which that kernel is running..
http://www.spielautomaten-fuehrer.de/
Post new comment