From nobody Mon Apr 29 16:33:16 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.39 as permitted sender) client-ip=209.132.183.39; envelope-from=libvir-list-bounces@redhat.com; helo=mx6-phx2.redhat.com; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.39 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; Return-Path: Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) by mx.zohomail.com with SMTPS id 1489409720702279.9565351742169; Mon, 13 Mar 2017 05:55:20 -0700 (PDT) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2DCponc039760; Mon, 13 Mar 2017 08:51:51 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v2DCpn2i018920 for ; Mon, 13 Mar 2017 08:51:49 -0400 Received: from t460.redhat.com (ovpn-116-20.ams2.redhat.com [10.36.116.20]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2DCpkQS008709; Mon, 13 Mar 2017 08:51:47 -0400 From: "Daniel P. Berrange" To: libvir-list@redhat.com Date: Mon, 13 Mar 2017 12:51:40 +0000 Message-Id: <20170313125140.28502-1-berrange@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] Switch to GSSAPI (kerberos) instead of the insecure DIGEST-MD5 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" RFC 6331 documents a number of serious security weaknesses in the SASL DIGEST-MD5 mechanism. As such, libvirtd should not by using it as a default mechanism. GSSAPI is the only other viable SASL mechanism that can provide secure session encryption so enable that by defalt as the replacement. Signed-off-by: Daniel P. Berrange --- daemon/libvirtd.sasl | 44 +++++++++++++++++--------- docs/auth.html.in | 89 +++++++++++++++++++++++++++++++++++++++++-------= ---- libvirt.spec.in | 6 ++-- 3 files changed, 102 insertions(+), 37 deletions(-) diff --git a/daemon/libvirtd.sasl b/daemon/libvirtd.sasl index 5e2528d..2be99ef 100644 --- a/daemon/libvirtd.sasl +++ b/daemon/libvirtd.sasl @@ -1,31 +1,45 @@ -# 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 the non-TLS socket, then you *must* pick a +# mechanism which provides session encryption as well 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 -mech_list: digest-md5 +# If you are only using UNIX, sockets then encryption is not +# required at all. +# +# Since SASL is the default for the libvirtd non-TLS socket, we +# pick a strong mechanism by default. +# +# NB, previously DIGEST-MD5 was set as the default mechanism for +# libvirt. 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 libvirtd service principal is +# added to the Kerberos server for each host running libvirtd. +# This principal needs to be exported to the keytab file listed below +mech_list: gssapi + +# If using a TLS socket or 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 +# +#mech_list: scram-sha-1 =20 -# 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 # # You can also list many mechanisms at once, then the user can choose # by adding '?auth=3Dsasl.gssapi' to their libvirt URI, eg # qemu+tcp://hostname/system?auth=3Dsasl.gssapi -#mech_list: digest-md5 gssapi +#mech_list: scram-sha-1 gssapi =20 # 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/libvirt/krb5.tab +keytab: /etc/libvirt/krb5.tab =20 -# 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 libvirt [username]' # to add entries, and 'sasldblistusers2 -f [sasldb_path]' to browse it -sasldb_path: /etc/libvirt/passwd.db +#sasldb_path: /etc/libvirt/passwd.db diff --git a/docs/auth.html.in b/docs/auth.html.in index 08feacc..9f2e317 100644 --- a/docs/auth.html.in +++ b/docs/auth.html.in @@ -204,16 +204,71 @@ ResultActive=3Dyes Further examples of PolicyKit setup can be found on the wiki page.

-

Username/password auth

+

SASL pluggable authentication

+

-The plain TCP socket of the libvirt daemon defaults to using SASL for auth= entication. -The SASL mechanism configured by default is DIGEST-MD5, which provides a b= asic -username+password style authentication. It also provides for encryption of= the data -stream, so the security of the plain TCP socket is on a par with that of t= he TLS -socket. If desired the UNIX socket and TLS socket can also have SASL enabl= ed by -setting the auth_unix_ro, auth_unix_rw, au= th_tls -config params in libvirt.conf. -

+Libvirt integrates with the cyrus-sasl library to provide a pluggable auth= entication +system using the SASL protocol. SASL can be used in combination with libvi= rtd's TLS +or TCP socket listeners. When used with the TCP listener, the SASL mechani= sm is +rqeuired to provide session encryption in addition to authentication. Only= a very +few SASL mechanisms are able todo this, and of those that can do it, only = the +GSSAPI plugin is considered acceptably secure by modern standards: +

+ +
+
GSSAPI
+
This is the current default mechanism to use with libvir= td. + It uses the Kerberos v5 authentication protocol underneath, and as= suming + the Kerberos client/server are configured with modern ciphers (AES= ), + it provides strong session encryption capabilities.
+ +
DIGEST-MD5
+
This was previously set as the default mechanism to use with lib= virtd. + It provides a simple username/password based authentication mechan= ism + that includes session encryption. + RFC 6331, howe= ver, + documents a number of serious security flaws with DIGEST-MD5 and a= s a + result marks it as OBSOLETE. Specific concerns are th= at + it is vulnerable to MITM attacks and the MD5 hash can be brute-for= ced + to reveal the password. A replacement is provided via the SCRAM me= chanism, + however, note that this is does not provide encryption, so the SCR= AM + mechanism can only be used on the libvirtd TLS listener. +
+ +
PASSDSS-3DES-1
+
This provides a simple username/password based authentication + mechanism that includes session encryption. The current cyrus-sasl + implementation does not provide a way to validate the server's + public key identity, thus it is susceptible to a MITM attacker + impersonating the server.
+ +
KERBEROS_V4
+
This uses the obsolete Kerberos v4 protocol to provide both auth= entication + and session encryption. Kerberos v4 protocol has been obsolete sin= ce the + early 1990's and has known security vulnerabilities so this will n= ever be + used in practice.
+
+ +

+ Other SASL mechanisms, not listed above, can only be used when the l= ibvirtd + TLS or UNIX socket listeners. +

+ +

Username/password auth

+

+As noted above, the DIGEST-MD5 mechanism is considered obsolete and should +not be used anymore. To provide a simple username/password auth scheme on +the libvirt UNIX socket or TLS listeners, however, it is possible to use +the SCRAM mechanism. The auth_unix_ro, auth_unix_rw, +auth_tls config params in libvirt.conf can be us= ed +to turn on SASL auth in these listeners. +

+

+Since the libvirt SASL config file defaults to using GSSAPI (Kerberos), a +config change is rquired to enable plain password auth. This is done by +editting /etc/sasl2/libvirt.conf to set the mech_list +parameter to scram-sha-1. +

Out of the box, no user accounts are defined, so no clients will be able t= o authenticate on the TCP socket. Adding users and setting their passwords is done with t= he saslpasswd2 @@ -241,17 +296,13 @@ again: 

 # saslpasswd2 -a libvirt -d fred
-

Kerberos auth

+

GSSAPI/Kerberos auth

-The plain TCP socket of the libvirt daemon defaults to using SASL for auth= entication. -The SASL mechanism configured by default is DIGEST-MD5, which provides a b= asic -username+password style authentication. To enable Kerberos single-sign-on = instead, -the libvirt SASL configuration file must be changed. This is /etc/sa= sl2/libvirt.conf. -The mech_list parameter must first be changed to gssapi= -instead of the default digest-md5, and keytab should be set to -/etc/libvirt/krb5.tab . If SASL is enabled on the UNIX -and/or TLS sockets, Kerberos will also be used for them. Like DIGEST-MD5, = the Kerberos -mechanism provides data encryption of the session. +The plain TCP listener of the libvirt daemon defaults to using SASL for au= thentication. +The libvirt SASL config also defaults to GSSAPI, so there is no need to ed= it the +SASL config when using GSSAPI. If the libvirtd TLS or UNIX listeners are u= sed, +then the Kerberos session encryption will be disabled since it is not requ= ired +in these scenarios - only the plain TCP listener needs encryption

Some operating systems do not install the SASL kerberos plugin by default.= It diff --git a/libvirt.spec.in b/libvirt.spec.in index 57ac88e..1d24985 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -979,9 +979,9 @@ Group: Development/Libraries # (client invokes 'nc' against the UNIX socket on the server) Requires: nc Requires: cyrus-sasl -# Not technically required, but makes 'out-of-box' config -# work correctly & doesn't have onerous dependencies -Requires: cyrus-sasl-md5 +# Needed by default sasl.conf - no onerous extra deps, since +# 100's of other things on a system already pull in krb5-libs +Requires: cyrus-sasl-gssapi =20 %description libs Shared libraries for accessing the libvirt daemon. --=20 2.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list