1.. _VNC security: 2 3VNC security 4------------ 5 6The VNC server capability provides access to the graphical console of 7the guest VM across the network. This has a number of security 8considerations depending on the deployment scenarios. 9 10.. _vnc_005fsec_005fnone: 11 12Without passwords 13~~~~~~~~~~~~~~~~~ 14 15The simplest VNC server setup does not include any form of 16authentication. For this setup it is recommended to restrict it to 17listen on a UNIX domain socket only. For example 18 19.. parsed-literal:: 20 21 |qemu_system| [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc 22 23This ensures that only users on local box with read/write access to that 24path can access the VNC server. To securely access the VNC server from a 25remote machine, a combination of netcat+ssh can be used to provide a 26secure tunnel. 27 28.. _vnc_005fsec_005fpassword: 29 30With passwords 31~~~~~~~~~~~~~~ 32 33The VNC protocol has limited support for password based authentication. 34Since the protocol limits passwords to 8 characters it should not be 35considered to provide high security. The password can be fairly easily 36brute-forced by a client making repeat connections. For this reason, a 37VNC server using password authentication should be restricted to only 38listen on the loopback interface or UNIX domain sockets. Password 39authentication is not supported when operating in FIPS 140-2 compliance 40mode as it requires the use of the DES cipher. Password authentication 41is requested with the ``password`` option, and then once QEMU is running 42the password is set with the monitor. Until the monitor is used to set 43the password all clients will be rejected. 44 45.. parsed-literal:: 46 47 |qemu_system| [...OPTIONS...] -vnc :1,password -monitor stdio 48 (qemu) change vnc password 49 Password: ******** 50 (qemu) 51 52.. _vnc_005fsec_005fcertificate: 53 54With x509 certificates 55~~~~~~~~~~~~~~~~~~~~~~ 56 57The QEMU VNC server also implements the VeNCrypt extension allowing use 58of TLS for encryption of the session, and x509 certificates for 59authentication. The use of x509 certificates is strongly recommended, 60because TLS on its own is susceptible to man-in-the-middle attacks. 61Basic x509 certificate support provides a secure session, but no 62authentication. This allows any client to connect, and provides an 63encrypted session. 64 65.. parsed-literal:: 66 67 |qemu_system| [...OPTIONS...] \ 68 -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=no \ 69 -vnc :1,tls-creds=tls0 -monitor stdio 70 71In the above example ``/etc/pki/qemu`` should contain at least three 72files, ``ca-cert.pem``, ``server-cert.pem`` and ``server-key.pem``. 73Unprivileged users will want to use a private directory, for example 74``$HOME/.pki/qemu``. NB the ``server-key.pem`` file should be protected 75with file mode 0600 to only be readable by the user owning it. 76 77.. _vnc_005fsec_005fcertificate_005fverify: 78 79With x509 certificates and client verification 80~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 81 82Certificates can also provide a means to authenticate the client 83connecting. The server will request that the client provide a 84certificate, which it will then validate against the CA certificate. 85This is a good choice if deploying in an environment with a private 86internal certificate authority. It uses the same syntax as previously, 87but with ``verify-peer`` set to ``yes`` instead. 88 89.. parsed-literal:: 90 91 |qemu_system| [...OPTIONS...] \ 92 -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ 93 -vnc :1,tls-creds=tls0 -monitor stdio 94 95.. _vnc_005fsec_005fcertificate_005fpw: 96 97With x509 certificates, client verification and passwords 98~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 99 100Finally, the previous method can be combined with VNC password 101authentication to provide two layers of authentication for clients. 102 103.. parsed-literal:: 104 105 |qemu_system| [...OPTIONS...] \ 106 -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ 107 -vnc :1,tls-creds=tls0,password -monitor stdio 108 (qemu) change vnc password 109 Password: ******** 110 (qemu) 111 112.. _vnc_005fsec_005fsasl: 113 114With SASL authentication 115~~~~~~~~~~~~~~~~~~~~~~~~ 116 117The SASL authentication method is a VNC extension, that provides an 118easily extendable, pluggable authentication method. This allows for 119integration with a wide range of authentication mechanisms, such as PAM, 120GSSAPI/Kerberos, LDAP, SQL databases, one-time keys and more. The 121strength of the authentication depends on the exact mechanism 122configured. If the chosen mechanism also provides a SSF layer, then it 123will encrypt the datastream as well. 124 125Refer to the later docs on how to choose the exact SASL mechanism used 126for authentication, but assuming use of one supporting SSF, then QEMU 127can be launched with: 128 129.. parsed-literal:: 130 131 |qemu_system| [...OPTIONS...] -vnc :1,sasl -monitor stdio 132 133.. _vnc_005fsec_005fcertificate_005fsasl: 134 135With x509 certificates and SASL authentication 136~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 137 138If the desired SASL authentication mechanism does not supported SSF 139layers, then it is strongly advised to run it in combination with TLS 140and x509 certificates. This provides securely encrypted data stream, 141avoiding risk of compromising of the security credentials. This can be 142enabled, by combining the 'sasl' option with the aforementioned TLS + 143x509 options: 144 145.. parsed-literal:: 146 147 |qemu_system| [...OPTIONS...] \ 148 -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ 149 -vnc :1,tls-creds=tls0,sasl -monitor stdio 150 151.. _vnc_005fsetup_005fsasl: 152 153Configuring SASL mechanisms 154~~~~~~~~~~~~~~~~~~~~~~~~~~~ 155 156The following documentation assumes use of the Cyrus SASL implementation 157on a Linux host, but the principles should apply to any other SASL 158implementation or host. When SASL is enabled, the mechanism 159configuration will be loaded from system default SASL service config 160/etc/sasl2/qemu.conf. If running QEMU as an unprivileged user, an 161environment variable SASL_CONF_PATH can be used to make it search 162alternate locations for the service config file. 163 164If the TLS option is enabled for VNC, then it will provide session 165encryption, otherwise the SASL mechanism will have to provide 166encryption. In the latter case the list of possible plugins that can be 167used is drastically reduced. In fact only the GSSAPI SASL mechanism 168provides an acceptable level of security by modern standards. Previous 169versions of QEMU referred to the DIGEST-MD5 mechanism, however, it has 170multiple serious flaws described in detail in RFC 6331 and thus should 171never be used any more. The SCRAM-SHA-1 mechanism provides a simple 172username/password auth facility similar to DIGEST-MD5, but does not 173support session encryption, so can only be used in combination with TLS. 174 175When not using TLS the recommended configuration is 176 177:: 178 179 mech_list: gssapi 180 keytab: /etc/qemu/krb5.tab 181 182This says to use the 'GSSAPI' mechanism with the Kerberos v5 protocol, 183with the server principal stored in /etc/qemu/krb5.tab. For this to work 184the administrator of your KDC must generate a Kerberos principal for the 185server, with a name of 'qemu/somehost.example.com@EXAMPLE.COM' replacing 186'somehost.example.com' with the fully qualified host name of the machine 187running QEMU, and 'EXAMPLE.COM' with the Kerberos Realm. 188 189When using TLS, if username+password authentication is desired, then a 190reasonable configuration is 191 192:: 193 194 mech_list: scram-sha-1 195 sasldb_path: /etc/qemu/passwd.db 196 197The ``saslpasswd2`` program can be used to populate the ``passwd.db`` 198file with accounts. 199 200Other SASL configurations will be left as an exercise for the reader. 201Note that all mechanisms, except GSSAPI, should be combined with use of 202TLS to ensure a secure data channel. 203