8.1 Authentication

The power to manage VM Guests and to access their graphical console obviously is something that should be restricted to a well defined circle of persons. In order to achieve this goal, you can use the following authentication techniques on the VM Host Server:

  • Access control for UNIX sockets with permissions and group ownership. This method is available for libvirtd connections only.

  • Access control for UNIX sockets with PolicyKit. This method is available for local libvirtd connections only.

  • Username and password authentication with SASL (Simple Authentication and Security Layer). This method is available for both, libvirtd and VNC connections. Using SASL does not require real user accounts on the server, since it uses its own database to store usernames and passwords. Connections authenticated with SASL are encrypted.

  • Kerberos authentication. This method, available for libvirtd connections only, is not covered in this manual. Please refer to http://libvirt.org/auth.html#ACL_server_kerberos for details.

  • Single password authentication. This method is available for VNC connections only.

IMPORTANT: Authentication for libvirtd and VNC need to be configured separately

Access to the VM Guest management functions (via libvirtd) on the one hand and to their graphical console on the other hand, always needs to be configured separately. When restricting the access to the management tools, these restrictions do not automatically apply to VNC connections!

When accessing VM Guests from remote via TLS/SSL connections, access can be indirectly controlled on each client by restricting read permissions to the certificate's key file to a certain group. See Restricting Access (Security Considerations) for details.

8.1.1 libvirtd Authentication

libvirtd authentication is configured in /etc/libvirt/libvirtd.conf. The configuration made here applies to all libvirt tools such as the Virtual Machine Manager or virsh.

libvirt offers two sockets: a read-only socket for monitoring purposes and a read-write socket to be used for management operations. Access to both sockets can be configured independently. By default, both sockets are owned by root.root. Default access permissions on the read-write socket are restricted to the user root (0700) and fully open on the read-only socket (0777).

In the following instructions you learn how to configure access permissions for the read-write socket. The same instructions also apply to the read-only socket. All configuration steps have to be carried out on the VM Host Server.

NOTE: Default Authentication Settings on SUSE Linux Enterprise Server

The default authentication method on SUSE Linux Enterprise Server is access control for UNIX sockets. Only the user root may authenticate. When accessing the libvirt tools as a non-root user directly on the VM Host Server, you need to provide the root password through PolicyKit once and are granted access for the current and for future sessions.

Alternatively you can configure libvirt to allow system access to non-privileged users. See Section 8.3.1, system Access for Non-Privileged Users for details.

Recommended Authorization Methods
Local Connections
Remote Tunnel over SSH
Remote TLS/SSL Connection

Access Control for UNIX Sockets with Permissions and Group Ownership

In order to grant access for non-root accounts, configure the sockets to be owned and accessible by a certain group (libvirt in the following example). This authentication method can be used for local and remote SSH connections.

  1. In case it does not exist, create the group which should own the socket:

    groupadd libvirt

    IMPORTANT: Group Needs to Exist

    The group must exist prior to restarting libvirtd. If not, the restart will fail.

  2. Add the desired users to the group:

    usermod -A libvirt tux
  3. Change the configuration in /etc/libvirt/libvirtd.conf as follows:

    unix_sock_group = "libvirt"
           unix_sock_rw_perms = "0770"
           auth_unix_rw = "none"

    Group ownership will be set to group libvirt.

    Sets the access permissions for the socket (srwxrwx---).

    Disables other authentication methods (PolicyKit or SASL). Access is solely controlled by the socket permissions.

  4. Restart libvirtd:

    rclibvirtd restart

Local Access Control for UNIX Sockets with PolicyKit

Access control for UNIX sockets with PolicyKit is the default authentication method on SUSE Linux Enterprise Server for non-remote connections. Therefore, no libvirt configuration changes are needed. With PolicyKit authorization enabled, permissions on both sockets default to 0777 and each application trying to access a socket needs to authenticate via PolicyKit. SUSE Linux Enterprise Server

IMPORTANT: PolicyKit Authentication for Local Connections Only

Authentication with PolicyKit can only be used for local connections on the VM Host Server itself, since PolicyKit does not handle remote authentication.

Two policies for accessing libvirt's sockets exist:

  • org.libvirt.unix.monitor: accessing the read-only socket

  • org.libvirt.unix.manage: accessing the read-write socket

By default, the policy for accessing the read-write socket is to authenticate with root password once and grant the privilege for the current and for future sessions (auth_admin_keep_always).

In order to grant users access to the read-write socket without having to provide the root password, there are two possibilities:

  1. Using the polkit-auth command, you can grant the privilege without any restrictions:

    polkit-auth --user tux --grant org.libvirt.unix.manage    # grant privilege
    polkit-auth --user tux --revoke org.libvirt.unix.manage   # revoke privilege
  2. Editing /etc/PolicyKit/PolicyKit.conf offers more advanced options. Add the following XML snippet in between the existing <config version="0.1"> and </config> tags:

    <match action="org.libvirt.unix.manage">
      <match user="tux">
        <return result="yes"/>
      </match>
    </match>

    The name of the policy; org.libvirt.unix.manage stands for accessing the read-write socket.

    The username(s) which to grant the privilege. Use the | symbol to separate entries (user="tux|wilber").

    The privilege that is granted. The following options exist: yes (no restrictions), no (block access completely), auth_self or auth_admin (authenticate with own password/root password every time the privilege is requested), auth_self_keep_session or auth_admin_keep_session (authenticate with own password/root password once per session) and auth_self_keep_always or auth_admin_keep_always (authenticate only once with own password/root password).

Username and Password Authentication with SASL

SASL provides username and password authentication as well as data encryption (digest-md5, by default). Since SASL maintains its own user database, the users do not need to exist on the VM Host Server. SASL is required by TCP connections and on top of TLS/SSL connections.

IMPORTANT: Plain TCP and SASL with digest-md5 Encryption

Using digest-md5 encryption on an otherwise unencrypted TCP connection does not provide enough security for production environments. It is recommended to only use it in testing environments.

HINT: SASL Authentication on Top of TLS/SSL

Access from remote TLS/SSL connections can be indirectly controlled on the client side by restricting access to the certificate's key file. However, this might prove error-prone when dealing with a large number of clients. Utilizing SASL with TLS adds security by additionally controlling access on the server side.

To configure SASL authentication, proceed as follows:

  1. Change the configuration in /etc/libvirt/libvirtd.conf as follows:

    1. To enable SASL for TCP connections:

      auth_tcp = "sasl"
    2. To enable SASL for TLS/SSL connections:

      auth_tls = "sasl"
  2. Restart libvirtd:

    rclibvirtd restart
  3. The libvirt SASL configuration file is located at /etc/sasl2/libvirtd.conf. Normally, there is no need to change the defaults. However, if using SASL on top of TLS, you may turn off session encryption to avoid additional overhead— TLS connections are already encrypted— by commenting the mech_list. For TCP connections this parameter must be set to digest-md5:

    mech_list: digest-md5   # mandatory for TCP connections
    #mech_list: digest-md5   # apply default (username+password) TLS/SSL only!
  4. By default, no SASL users are configured, so no logins are possible. Use the following commands to add, list, and delete users:

    mercury:~ # saslpasswd2 -a libvirt tux                  # add user tux
    Password: 
    Again (for verification): 
    mercury:~ # sasldblistusers2 -f /etc/libvirt/passwd.db  # list users
    tux@mercury.example.com: userPassword
    mercury:~ # saslpasswd2 -a libvirt -d tux               # delete user tux

HINT: virsh and SASL Authentication

When using SASL authentication you will be prompted for a username and password every time you issue a virsh command. Avoid this by using virsh in shell mode.

8.1.2 VNC Authentication

Since access to the graphical console of a VM Guest is not controlled by libvirt, but rather by QEMU, it is always necessary to additionally configure VNC authentication. The main configuration file is /etc/libvirt/qemu.conf.

Two authentication types are available: SASL and single password authentication. If you are using SASL for libvirt authentication, it is strongly recommended to use it for VNC authentication as well—it is possible to share the same database.

A third method to restrict access to the VM Guest is to enable the use of TLS encryption on the VNC server. This requires the VNC clients to have access to x509 client certificates. By restricting access to these certificates, access can indirectly be controlled on the client side. Refer to VNC over TLS/SSL: Client Configuration for details.

Username and Password Authentication with SASL

SASL provides username and password authentication as well as data encryption. Since SASL maintains its own user database, the users do not need to exist on the VM Host Server. As with SASL authentication for libvirt, you may use SASL on top of TLS/SSL connections. Refer to VNC over TLS/SSL: Client Configuration for details on configuring these connections.

To configure SASL authentication for VNC, proceed as follows:

  1. Create a SASL configuration file. It is recommended to use the existing libvirt file. If you have already configured SASL for libvirt and are planning to use the same settings including the same username/password database, a simple link is suitable:

    ln -s /etc/sasl2/libvirt.conf /etc/sasl2/qemu.conf

    In case you are setting up SASL for VNC only or planning to use a different configuration than for libvirt, copy the existing file to use as a template and edit it according to your needs:

    cp /etc/sasl2/libvirt.conf /etc/sasl2/qemu.conf
  2. By default, no SASL users are configured, so no logins are possible. Use the following commands to add, list, and delete users:

    mercury:~ # saslpasswd2 -a libvirt tux                  # add user tux
    Password: 
    Again (for verification): 
    mercury:~ # sasldblistusers2 -f /etc/libvirt/passwd.db  # list users
    tux@mercury.example.com: userPassword
    mercury:~ # saslpasswd2 -a libvirt -d tux               # delete user tux
  3. Change the configuration in /etc/libvirt/qemu.conf as follows:

    vnc_listen = "0.0.0.0"
    vnc_sasl = 1

    The first parameter enables VNC to listen on all public interfaces (rather than to the local host only), and the second parameter enables SASL authentication.

  4. Restart libvirtd:

    rclibvirtd restart
  5. Restart all VM Guests that have been running prior to changing the configuration. VM Guests that have not been restarted will not use SASL authentication for VNC connects.

NOTE: Supported VNC Viewers

Currently only the same VNC viewers that also support TLS/SSL connections, support SASL authentication, namely Virtual Machine Manager, virt-viewer, and vinagre.

Single Password Authentication

Access to the VNC server may also be controlled by setting a VNC password. You can either set a global password for all VM Guests or set individual passwords for each guest. The latter requires to edit the VM Guest's config files.

NOTE: Always Set a Global Password

If you are using the single password authentication, it is good practice to set a global password even if setting passwords for each VM Guest. This will always leave your virtual machines protected with a fallback password if you forget to set a per-machine password. The global password will only be used if no other password is set for the machine.

Setting a Global VNC Password

  1. Change the configuration in /etc/libvirt/qemu.conf as follows:

    vnc_listen = "0.0.0.0"
           vnc_password = "PASSWORD"

    The first parameter enables VNC to listen on all public interfaces (rather than to the local host only), and the second parameter sets the password. The maximum length of the password is eight characters.

  2. Restart libvirtd:

    rclibvirtd restart
  3. Restart all VM Guests that have been running prior to changing the configuration. VM Guests that have not been restarted will not use password authentication for VNC connects.

Setting a VM Guest Specific VNC Password

  1. Change the configuration in /etc/libvirt/qemu.conf as follows to enable VNC to listen on all public interfaces (rather than to the local host only).

    vnc_listen = "0.0.0.0"
  2. Open the VM Guest's XML configuration file in an editor. Replace VM NAME in the following example with the name of the VM Guest. The editor that is used defaults to $EDITOR. If that variable is not set, vi is used.

    virsh edit VM NAME
  3. Search for the element <graphics> with the attribute type='vnc', for example:

    <graphics type='vnc' port='-1' autoport='yes'/>
  4. Add the passwd=PASSWORD attribute, save the file and leave the editor. The maximum length of the password is eight characters.

    <graphics type='vnc' port='-1' autoport='yes' passwd='PASSWORD'/>
  5. Restart libvirtd:

    rclibvirtd restart
  6. Restart all VM Guests that have been running prior to changing the configuration. VM Guests that have not been restarted will not use password authentication for VNC connects.

WARNING: Security

The VNC protocol is not considered to be safe. Although the password is sent encrypted, it might be vulnerable, when an attacker is able to sniff both, the encrypted password and the encryption key. Therefore, it is recommended to use VNC with TLS/SSL or tunneled over SSH. virt-viewer, as well as the Virtual Machine Manager and vinagre from version 2.30 on, support both methods.