Browse Source

Default to GSSAPI (Kerberos) instead of DIGEST-MD5 for SASL

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.

Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
tags/v2.10.0-rc0
Daniel P. Berrange 2 years ago
parent
commit
c6a9a9f575
2 changed files with 60 additions and 44 deletions
  1. 29
    21
      qemu-doc.texi
  2. 31
    23
      qemu.sasl

+ 29
- 21
qemu-doc.texi View File

@@ -1732,37 +1732,45 @@ SASL service config /etc/sasl2/qemu.conf. If running QEMU as an
1732 1732
 unprivileged user, an environment variable SASL_CONF_PATH can be used
1733 1733
 to make it search alternate locations for the service config.
1734 1734
 
1735
-The default configuration might contain
1735
+If the TLS option is enabled for VNC, then it will provide session encryption,
1736
+otherwise the SASL mechanism will have to provide encryption. In the latter
1737
+case the list of possible plugins that can be used is drastically reduced. In
1738
+fact only the GSSAPI SASL mechanism provides an acceptable level of security
1739
+by modern standards. Previous versions of QEMU referred to the DIGEST-MD5
1740
+mechanism, however, it has multiple serious flaws described in detail in
1741
+RFC 6331 and thus should never be used any more. The SCRAM-SHA-1 mechanism
1742
+provides a simple username/password auth facility similar to DIGEST-MD5, but
1743
+does not support session encryption, so can only be used in combination with
1744
+TLS.
1745
+
1746
+When not using TLS the recommended configuration is
1736 1747
 
1737 1748
 @example
1738
-mech_list: digest-md5
1739
-sasldb_path: /etc/qemu/passwd.db
1749
+mech_list: gssapi
1750
+keytab: /etc/qemu/krb5.tab
1740 1751
 @end example
1741 1752
 
1742
-This says to use the 'Digest MD5' mechanism, which is similar to the HTTP
1743
-Digest-MD5 mechanism. The list of valid usernames & passwords is maintained
1744
-in the /etc/qemu/passwd.db file, and can be updated using the saslpasswd2
1745
-command. While this mechanism is easy to configure and use, it is not
1746
-considered secure by modern standards, so only suitable for developers /
1747
-ad-hoc testing.
1753
+This says to use the 'GSSAPI' mechanism with the Kerberos v5 protocol, with
1754
+the server principal stored in /etc/qemu/krb5.tab. For this to work the
1755
+administrator of your KDC must generate a Kerberos principal for the server,
1756
+with a name of 'qemu/somehost.example.com@@EXAMPLE.COM' replacing
1757
+'somehost.example.com' with the fully qualified host name of the machine
1758
+running QEMU, and 'EXAMPLE.COM' with the Kerberos Realm.
1748 1759
 
1749
-A more serious deployment might use Kerberos, which is done with the 'gssapi'
1750
-mechanism
1760
+When using TLS, if username+password authentication is desired, then a
1761
+reasonable configuration is
1751 1762
 
1752 1763
 @example
1753
-mech_list: gssapi
1754
-keytab: /etc/qemu/krb5.tab
1764
+mech_list: scram-sha-1
1765
+sasldb_path: /etc/qemu/passwd.db
1755 1766
 @end example
1756 1767
 
1757
-For this to work the administrator of your KDC must generate a Kerberos
1758
-principal for the server, with a name of  'qemu/somehost.example.com@@EXAMPLE.COM'
1759
-replacing 'somehost.example.com' with the fully qualified host name of the
1760
-machine running QEMU, and 'EXAMPLE.COM' with the Kerberos Realm.
1768
+The saslpasswd2 program can be used to populate the passwd.db file with
1769
+accounts.
1761 1770
 
1762
-Other configurations will be left as an exercise for the reader. It should
1763
-be noted that only Digest-MD5 and GSSAPI provides a SSF layer for data
1764
-encryption. For all other mechanisms, VNC should always be configured to
1765
-use TLS and x509 certificates to protect security credentials from snooping.
1771
+Other SASL configurations will be left as an exercise for the reader. Note that
1772
+all mechanisms except GSSAPI, should be combined with use of TLS to ensure a
1773
+secure data channel.
1766 1774
 
1767 1775
 @node gdb_usage
1768 1776
 @section GDB usage

+ 31
- 23
qemu.sasl View File

@@ -1,36 +1,44 @@
1
-# If you want to use the non-TLS socket, then you *must* include
2
-# the GSSAPI or DIGEST-MD5 mechanisms, because they are the only
3
-# ones that can offer session encryption as well as authentication.
1
+# If you want to use VNC remotely without TLS, then you *must*
2
+# pick a mechanism which provides session encryption as well
3
+# as authentication.
4 4
 #
5
-# If you're only using TLS, then you can turn on any mechanisms
5
+# If you are only using TLS, then you can turn on any mechanisms
6 6
 # you like for authentication, because TLS provides the encryption
7 7
 #
8
-# Default to a simple username+password mechanism
9
-# NB digest-md5 is no longer considered secure by current standards
10
-mech_list: digest-md5
8
+# If you are only using UNIX sockets then encryption is not
9
+# required at all.
10
+#
11
+# NB, previously DIGEST-MD5 was set as the default mechanism for
12
+# QEMU VNC. Per RFC 6331 this is vulnerable to many serious security
13
+# flaws as should no longer be used. Thus GSSAPI is now the default.
14
+#
15
+# To use GSSAPI requires that a QEMU service principal is
16
+# added to the Kerberos server for each host running QEMU.
17
+# This principal needs to be exported to the keytab file listed below
18
+mech_list: gssapi
11 19
 
12
-# Before you can use GSSAPI, you need a service principle on the
13
-# KDC server for libvirt, and that to be exported to the keytab
14
-# file listed below
15
-#mech_list: gssapi
20
+# If using TLS with VNC, or a UNIX socket only, it is possible to
21
+# enable plugins which don't provide session encryption. The
22
+# 'scram-sha-1' plugin allows plain username/password authentication
23
+# to be performed
16 24
 #
17
-# You can also list many mechanisms at once, then the user can choose
18
-# by adding  '?auth=sasl.gssapi' to their libvirt URI, eg
19
-#   qemu+tcp://hostname/system?auth=sasl.gssapi
20
-#mech_list: digest-md5 gssapi
25
+#mech_list: scram-sha-1
26
+
27
+# You can also list many mechanisms at once, and the VNC server will
28
+# negotiate which to use by considering the list enabled on the VNC
29
+# client.
30
+#mech_list: scram-sha-1 gssapi
21 31
 
22 32
 # Some older builds of MIT kerberos on Linux ignore this option &
23 33
 # instead need KRB5_KTNAME env var.
24 34
 # For modern Linux, and other OS, this should be sufficient
25 35
 #
26
-# There is no default value here, uncomment if you need this
27
-#keytab: /etc/qemu/krb5.tab
36
+# This file needs to be populated with the service principal that
37
+# was created on the Kerberos v5 server. If switching to a non-gssapi
38
+# mechanism this can be commented out.
39
+keytab: /etc/qemu/krb5.tab
28 40
 
29
-# If using digest-md5 for username/passwds, then this is the file
41
+# If using scram-sha-1 for username/passwds, then this is the file
30 42
 # containing the passwds. Use 'saslpasswd2 -a qemu [username]'
31 43
 # to add entries, and 'sasldblistusers2 -f [sasldb_path]' to browse it
32
-sasldb_path: /etc/qemu/passwd.db
33
-
34
-
35
-auxprop_plugin: sasldb
36
-
44
+#sasldb_path: /etc/qemu/passwd.db

Loading…
Cancel
Save