On 03/15/2017 01:25 PM, Daniel P. Berrange wrote: > RFC 6331 documents a number of serious security weaknesses in > the SASL DIGEST-MD5 mechanism. As such, QEMU should not be > using or recommending it as a default mechanism for VNC auth > with SASL. > > GSSAPI (Kerberos) is the only other viable SASL mechanism that > can provide secure session encryption so enable that by defalt > as the replacement. If users have TLS enabled for VNC, they can > optionally decide to use SCRAM-SHA-1 instead of GSSAPI, allowing > plain username and password auth. > > Signed-off-by: Daniel P. Berrange <berra...@redhat.com> > --- > qemu-doc.texi | 50 +++++++++++++++++++++++++++++--------------------- > qemu.sasl | 54 +++++++++++++++++++++++++++++++----------------------- > 2 files changed, 60 insertions(+), 44 deletions(-) > > diff --git a/qemu-doc.texi b/qemu-doc.texi > index 794ab4a..922b3a4 100644 > --- a/qemu-doc.texi > +++ b/qemu-doc.texi > @@ -1732,37 +1732,45 @@ SASL service config /etc/sasl2/qemu.conf. If running > QEMU as an > unprivileged user, an environment variable SASL_CONF_PATH can be used > to make it search alternate locations for the service config. > > -The default configuration might contain > +If the TLS option is enabled for VNC, then it will provide session > encryption, > +otherwise the SASL mechanism will have to provide encryption. In the latter > +case the list of possible plugins that can be used is drastically reduced. In > +fact only the GSSAPI SASL mechanism provides an acceptable level of security > +by modern standards. Previous versions of QEMU referred to the DIGEST-MD5 > +mechansim, however, it has multiple serious flaws described in detail in
s/mechansim/mechanism/ > +RFC 6331 and thus should never be used any more. The SCRAM-SHA-1 mechanism > +provides a simple username/password auth facility similar to DIGEST-MD5, but > +does not support session encryption, so can only be used in conbination with s/conbination/combination/ > +TLS. > + > +When not using TLS the recommended configuration is > > @example > -mech_list: digest-md5 > -sasldb_path: /etc/qemu/passwd.db > +mech_list: gssapi > +keytab: /etc/qemu/krb5.tab > @end example > > -This says to use the 'Digest MD5' mechanism, which is similar to the HTTP > -Digest-MD5 mechanism. The list of valid usernames & passwords is maintained > -in the /etc/qemu/passwd.db file, and can be updated using the saslpasswd2 > -command. While this mechanism is easy to configure and use, it is not > -considered secure by modern standards, so only suitable for developers / > -ad-hoc testing. > +This says to use the 'GSSAPI' mechanism with the Kerberos v5 protocol, with > +the server principal stored in /etc/qemu/krb5.tab. For this to work the > +administrator of your KDC must generate a Kerberos principal for the server, > +with a name of 'qemu/somehost.example.com@@EXAMPLE.COM' replacing spurious double space > +'somehost.example.com' with the fully qualified host name of the machine > +running QEMU, and 'EXAMPLE.COM' with the Kerberos Realm. > > -A more serious deployment might use Kerberos, which is done with the 'gssapi' > -mechanism > +When using TLS, if username+password authentication is desired, then a > +reasonable configuration is > > @example > -mech_list: gssapi > -keytab: /etc/qemu/krb5.tab > +mech_list: scram-sha-1 > +sasldb_path: /etc/qemu/passwd.db > @end example > > -For this to work the administrator of your KDC must generate a Kerberos > -principal for the server, with a name of > 'qemu/somehost.example.com@@EXAMPLE.COM' > -replacing 'somehost.example.com' with the fully qualified host name of the > -machine running QEMU, and 'EXAMPLE.COM' with the Kerberos Realm. > +The saslpasswd2 program can be used to populate the passwd.db file with > +accounts. > > -Other configurations will be left as an exercise for the reader. It should > -be noted that only Digest-MD5 and GSSAPI provides a SSF layer for data > -encryption. For all other mechanisms, VNC should always be configured to > -use TLS and x509 certificates to protect security credentials from snooping. > +Other SASL configurations will be left as an exercise for the reader. Note > that > +all mechanisms except GSSAPI, should be combined with use of TLS to ensure a > +security data channel. s/security/secure/ ? > > @node gdb_usage > @section GDB usage > diff --git a/qemu.sasl b/qemu.sasl > index 64fdef3..8c501a1 100644 > --- a/qemu.sasl > +++ b/qemu.sasl > @@ -1,36 +1,44 @@ > -# If you want to use the non-TLS socket, then you *must* include > -# the GSSAPI or DIGEST-MD5 mechanisms, because they are the only > -# ones that can offer session encryption as well as authentication. > +# If you want to use VNC remotely without TLS, then you *must* > +# pick a mechanism which provides session encryption as well spurious double space > +# as authentication. > # > -# If you're only using TLS, then you can turn on any mechanisms > +# If you are only using TLS, then you can turn on any mechanisms > # you like for authentication, because TLS provides the encryption > # > -# Default to a simple username+password mechanism > -# NB digest-md5 is no longer considered secure by current standards > -mech_list: digest-md5 > +# If you are only using UNIX, sockets then encryption is not s/UNIX, sockets/UNIX sockets,/ > +# required at all. > +# > +# NB, previously DIGEST-MD5 was set as the default mechanism for > +# QEMU VNC. Per RFC 6331 this is vulnerable to many serious security > +# flaws as should no longer be used. Thus GSSAPI is now the default. > +# > +# To use GSSAPI requires that a QEMU service principal is > +# added to the Kerberos server for each host running QEMU. > +# This principal needs to be exported to the keytab file listed below > +mech_list: gssapi > > -# Before you can use GSSAPI, you need a service principle on the > -# KDC server for libvirt, and that to be exported to the keytab > -# file listed below > -#mech_list: gssapi > +# If using TLS with VNC, or a UNIX socket only, it is possible to > +# enable plugins which don't provide session encryption. The > +# 'scram-sha-1' plugin allows plain username/password authentication > +# to be performed > # > -# You can also list many mechanisms at once, then the user can choose > -# by adding '?auth=sasl.gssapi' to their libvirt URI, eg > -# qemu+tcp://hostname/system?auth=sasl.gssapi > -#mech_list: digest-md5 gssapi > +#mech_list: scram-sha-1 > + > +# You can also list many mechanisms at once, and the VNC server will > +# negotiate which to use by considering the list enabled on the VNC > +# client. > +#mech_list: scram-sha-1 gssapi > > # Some older builds of MIT kerberos on Linux ignore this option & > # instead need KRB5_KTNAME env var. > # For modern Linux, and other OS, this should be sufficient > # > -# There is no default value here, uncomment if you need this > -#keytab: /etc/qemu/krb5.tab > +# This file needs to be populated with the service principal that > +# was created on the Kerberos v5 server. If switching to a non-gssapi > +# mechanism this can be commented out. > +keytab: /etc/qemu/krb5.tab > > -# If using digest-md5 for username/passwds, then this is the file > +# If using scram-sha-1 for username/passwds, then this is the file > # containing the passwds. Use 'saslpasswd2 -a qemu [username]' > # to add entries, and 'sasldblistusers2 -f [sasldb_path]' to browse it > -sasldb_path: /etc/qemu/passwd.db > - > - > -auxprop_plugin: sasldb > - > +#sasldb_path: /etc/qemu/passwd.db > With typos fixed, Reviewed-by: Eric Blake <ebl...@redhat.com> -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature