From nobody Mon Feb 9 23:38:23 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) client-ip=216.205.24.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1614881436; cv=none; d=zohomail.com; s=zohoarc; b=hXMgGj6yVeVo0air9z/uu0qg4a10zS6wb98rPQpOIrvDPFqaVU6nhcx9q4qLJOTupF2+DWGsVc7Bt4uoDa/Iep2ArpcLuJs/wL/26xlDtc8lue3P2f/BdywzkJjKjLd87wn1XtByVju13RexAgx0vkh9EGH+fACh5oe7zXZEAM8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1614881436; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=DC0GqWrN9S6Ldk/6hzTPFB6YvUZb8mywfqVR2HLaRI4=; b=bpopetXUPrt7CcQh53+n57/28BToHzCPQ1kW3CllbLtC2eu8Br/OTtPZlrNiQ4jMWY33onj8NPd3Z6xz+5FXzRqjg+8+caJ/PEWxQ2D5aPRIn1J8c6Toh8X6EThX1RmyWBB0l10kMB0IqrvKkjw0QOFYC597KmAIlJGvEOmHiZY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.zohomail.com with SMTPS id 1614881436347869.160693976053; Thu, 4 Mar 2021 10:10:36 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-509-HRdT_hE3NHeGuj7u5xpaWg-1; Thu, 04 Mar 2021 13:10:31 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 00B9880006E; Thu, 4 Mar 2021 18:10:24 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D0E8960C0F; Thu, 4 Mar 2021 18:10:23 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 9AC4A5002E; Thu, 4 Mar 2021 18:10:23 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 124IAMDE006490 for ; Thu, 4 Mar 2021 13:10:22 -0500 Received: by smtp.corp.redhat.com (Postfix) id 0E07560C66; Thu, 4 Mar 2021 18:10:22 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-107.ams2.redhat.com [10.36.112.107]) by smtp.corp.redhat.com (Postfix) with ESMTP id 38F9B60C0F; Thu, 4 Mar 2021 18:10:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614881435; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=DC0GqWrN9S6Ldk/6hzTPFB6YvUZb8mywfqVR2HLaRI4=; b=OS7V+3AcjUqC8fU5hkc7oCLlZwhRRAkxTRLbnKwQqSUZ+afAYy/gMltcPARy/5KOwuzuBF FcBTiqEXKCcWi0qxzcW6fMQgT5PE3PmAKY1m+kZCz7C4MDkVSUlUcW3TLjxTap7j0/gA5O WAfy8+AO0t65NqV1Z4LMuUb3bI0XKbU= X-MC-Unique: HRdT_hE3NHeGuj7u5xpaWg-1 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Subject: [libvirt PATCH 2/2] docs: stop mentioning insecure / broken SASL mechanisms Date: Thu, 4 Mar 2021 18:10:13 +0000 Message-Id: <20210304181013.10329-3-berrange@redhat.com> In-Reply-To: <20210304181013.10329-1-berrange@redhat.com> References: <20210304181013.10329-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) We don't need to go to the trouble of telling users about existance of insecure SASL mechanisms only to then say that they shouldn't be used. We should only tell people about the GSSAPI mechanism for TCP sockets. For the SCRAM mechanism we should be telling people about the SHA256 variant only, and also warning that the password database stores the passwords in clear text. Signed-off-by: Daniel P. Berrang=C3=A9 --- docs/auth.rst | 67 ++++++++++++---------------------------- src/remote/libvirtd.sasl | 11 ++++--- 2 files changed, 26 insertions(+), 52 deletions(-) diff --git a/docs/auth.rst b/docs/auth.rst index 506e6b5c13..783ef9231b 100644 --- a/docs/auth.rst +++ b/docs/auth.rst @@ -207,61 +207,30 @@ with libvirtd's TLS or TCP socket listeners. When use= d with the TCP listener, the SASL mechanism is required to provide session encryption in addition to authentication. Only a very few SASL mechanisms are able to do 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 libvirtd*. - It uses the Kerberos v5 authentication protocol underneath, and assuming - 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 libvirtd. - It provides a simple username/password based authentication mechanism - that includes session encryption. - `RFC 6331` , however, - documents a number of serious security flaws with ``DIGEST-MD5`` and as a - result marks it as ``OBSOLETE``. Specific concerns are that - it is vulnerable to MITM attacks and the ``MD5`` hash can be brute-forced - to reveal the password. A replacement is provided via the ``SCRAM`` mech= anism, - however, note that this does not provide encryption, so the ``SCRAM`` - 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. It is also not enabled in many OS - distros when building SASL libraries. - -* **KERBEROS_V4**: - - This uses the obsolete Kerberos v4 protocol to provide both authenticati= on - and session encryption. Kerberos v4 protocol has been obsolete since the - early 1990's and has known security vulnerabilities so this will never be - used in practice. - -Other SASL mechanisms, not listed above, can only be used when the libvirtd -TLS or UNIX socket listeners. +by modern standards. ``GSSAPI`` is the default mechanism enabled in the li= bvirt +SASL configuration. It uses the Kerberos v5 authentication protocol undern= eath, +and assuming the Kerberos client/server are configured with modern ciphers +(AES), it provides strong session encryption capabilities. All other SASL +mechanisms should only be used with the libvirtd TLS or UNIX socket listen= ers. =20 Username/password auth ~~~~~~~~~~~~~~~~~~~~~~ =20 -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 used -to turn on SASL auth in these listeners. +To provide a simple username/password auth scheme on the libvirt UNIX sock= et +or TLS listeners, however, it is possible to use the ``SCRAM`` mechanism, = in its +``SCRAM-SHA-256`` variant. The ``auth_unix_ro``, ``auth_unix_rw``, ``auth_= tls`` +config params in ``libvirt.conf`` can be used to turn on SASL auth in these +listeners. =20 Since the libvirt SASL config file defaults to using ``GSSAPI`` (Kerberos)= , a config change is required to enable plain password auth. This is done by editing ``/etc/sasl2/libvirt.conf`` to set the ``mech_list`` -parameter to ``scram-sha-1``. +parameter to ``scram-sha-256``. + +**Note:** previous versions of libvirt suggested ``DIGEST-MD5`` and +``SCRAM-SHA-1`` mechanisms. Use of these is strongly discouraged as they a= re +not considered secure by modern standards. It is possible to replace them = with +use of ``SCRAM-SHA-256``, while still using the same password database. =20 Out of the box, no user accounts are defined, so no clients will be able to authenticate on the TCP socket. Adding users and setting their passwords is @@ -291,6 +260,10 @@ again: =20 # saslpasswd2 -a libvirt -d fred =20 +**Note:** the SASL ``passwd.db`` file stores passwords in clear text, so +care should be taken not to let its contents be disclosed to unauthorized +users. + GSSAPI/Kerberos auth ~~~~~~~~~~~~~~~~~~~~ =20 diff --git a/src/remote/libvirtd.sasl b/src/remote/libvirtd.sasl index 7a45470a9d..53596c7c9d 100644 --- a/src/remote/libvirtd.sasl +++ b/src/remote/libvirtd.sasl @@ -22,22 +22,23 @@ mech_list: gssapi =20 # 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 +# 'scram-sha-256' plugin allows plain username/password authentication # to be performed # -#mech_list: scram-sha-1 +#mech_list: scram-sha-256 =20 # # 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: scram-sha-1 gssapi +#mech_list: scram-sha-256 gssapi =20 # File containing the service principal for libvirtd # keytab: /etc/libvirt/krb5.tab =20 -# If using scram-sha-1 for username/passwds, then this is the file +# If using scram-sha-256 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 +# to add entries, and 'sasldblistusers2 -f [sasldb_path]' to browse it. +# Note that this file stores passwords in clear text. #sasldb_path: /etc/libvirt/passwd.db --=20 2.29.2