From nobody Sun May 12 13:56:57 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1621013617; cv=none; d=zohomail.com; s=zohoarc; b=M6l5q49USLqYvvDSxRbBVHg7EFobOyiKa54euW5w5zAdXFxAho7Ew051TYHa2AIeYxoz6rZ4UOE+LW7DBJDhvuC0yBVfc24bxdHaZLLXoA991Kn9l+nSadR/gu6x+QnKNyF5DiobJaYysCv5fpLZlu8vvTkKpol3WZVQRKs0oMs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1621013617; h=Content-Type:Content-Transfer-Encoding:Cc: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=kXiuL+S3bOhDnw7FB5KqwGkHnt4PhdzWiMToBZ4Q2iw=; b=kS6+ly1anSG3tj0f4hE+p6B6+VdHFTyvsrtQJ3e7/93Sb1S9kzklo9lGRm//tfFpr9jsEunp5nX2z50I04JSrKAE9Ecppg+q68XvL01jD9n2/o7/yKPv8hlJIoem7TPvKo4isYKV2M54Rf6K/7QbhMpMNPWeWECaS+wir/OPcKI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1621013617652927.3407328860435; Fri, 14 May 2021 10:33:37 -0700 (PDT) Received: from localhost ([::1]:52830 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhbgu-0005rl-3r for importer@patchew.org; Fri, 14 May 2021 13:33:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhbeh-0002tI-JR for qemu-devel@nongnu.org; Fri, 14 May 2021 13:31:19 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:25129) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhbef-0007cB-9H for qemu-devel@nongnu.org; Fri, 14 May 2021 13:31:19 -0400 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-266-KOTQdw-4MLem6LLHh2oKKw-1; Fri, 14 May 2021 13:31:13 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3042391270 for ; Fri, 14 May 2021 17:31:13 +0000 (UTC) Received: from localhost.redhat.com (ovpn-113-212.ams2.redhat.com [10.36.113.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id 21FBF5C1C4; Fri, 14 May 2021 17:31:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621013476; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kXiuL+S3bOhDnw7FB5KqwGkHnt4PhdzWiMToBZ4Q2iw=; b=O+5eP50E16byzsTUeRg5ZEiqeBUOV247rm6khdubh3DyT/mkrHZ0YnrnI4Yg0K/aosVAtA MpvgHtbH4Pow7b/2HjXHD4YbrKkZhW6BhDltMYJDD1NPzCbfyLLhU/peMxdgaTNuv1qJJi 3qpmZy9BNjGEr5v3qBBxuPAPzXAJC1A= X-MC-Unique: KOTQdw-4MLem6LLHh2oKKw-1 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH 1/4] docs: document how to pass secret data to QEMU Date: Fri, 14 May 2021 18:31:07 +0100 Message-Id: <20210514173110.1397741-2-berrange@redhat.com> In-Reply-To: <20210514173110.1397741-1-berrange@redhat.com> References: <20210514173110.1397741-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.699, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Marc-Andr=C3=A9 Lureau --- docs/system/index.rst | 1 + docs/system/secrets.rst | 162 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+) create mode 100644 docs/system/secrets.rst diff --git a/docs/system/index.rst b/docs/system/index.rst index b05af716a9..6aa2f8c05c 100644 --- a/docs/system/index.rst +++ b/docs/system/index.rst @@ -30,6 +30,7 @@ Contents: guest-loader vnc-security tls + secrets gdb managed-startup cpu-hotplug diff --git a/docs/system/secrets.rst b/docs/system/secrets.rst new file mode 100644 index 0000000000..4a177369b6 --- /dev/null +++ b/docs/system/secrets.rst @@ -0,0 +1,162 @@ +.. _secret data: + +Providing secret data to QEMU +----------------------------- + +There are a variety of objects in QEMU which require secret data to be pro= vided +by the administrator or management application. For example, network block +devices often require a password, LUKS block devices require a passphrase = to +unlock key material, remote desktop services require an access password. +QEMU has a general purpose mechanism for providing secret data to QEMU in a +secure manner, using the ``secret`` object type. + +At startup this can be done using the ``-object secret,...`` command line +argument. At runtime this can be done using the ``object_add`` QMP / HMP +monitor commands. The examples that follow will illustrate use of ``-objec= t`` +command lines, but they all apply equivalentely in QMP / HMP. When creating +a ``secret`` object it must be given a unique ID string. This ID is then +used to identify the object when configuring the thing which need the data. + + +INSECURE: Passing secrets as clear text inline +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**The following should never be done in a production environment or on a +multi-user host. Command line arguments are usually visible in the process +listings and are often collected in log files by system monitoring agents +or bug reporting tools. QMP/HMP commands and their arguments are also often +logged and attached to bug reports. This all risks compromising secrets th= at +are passed inline.** + +For the convenience of people debugging / developing with QEMU, it is poss= ible +to pass secret data inline on the command line. + +:: + + -object secret,id=3Dsecvnc0,data=3D87539319 + + +Again it is possible to provide the data in base64 encoded format, which is +particularly useful if the data contains binary characters that would clash +with argument parsing. + +:: + + -object secret,id=3Dsecvnc0,data=3DODc1MzkzMTk=3D,format=3Dbase64 + + +**Note: base64 encoding does not provide any security benefit.** + +Passing secrets as clear text via a file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The simplest approach to providing data securely is to use a file to store +the secret: + +:: + + -object secret,id=3Dsecvnc0,file=3Dvnc-password.txt + + +In this example the file ``vnc-password.txt`` contains the plain text secr= et +data. It is important to note that the contents of the file are treated as= an +opaque blob. The entire raw file contents is used as the value, thus it is +important not to mistakenly add any trailing newline character in the file= if +this newline is not intended to be part of the secret data. + +In some cases it might be more convenient to pass the secret data in base64 +format and have QEMU decode to get the raw bytes before use: + +:: + + -object secret,id=3Dsec0,file=3Dvnc-password.txt,format=3Dbase64 + + +The file should generally be given mode ``0600`` or ``0400`` permissions, = and +have its user/group ownership set to the same account that the QEMU process +will be launched under. If using mandatory access control such as SELinux,= then +the file should be labelled to only grant access to the specific QEMU proc= ess +that needs access. This will prevent other processes/users from compromisi= ng the +secret data. + + +Passing secrets as cipher text inline +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To address the insecurity of passing secrets inline as clear text, it is +possible to configure a second secret as an AES key to use for decrypting +the data. + +The secret used as the AES key must always be configured using the file ba= sed +storage mechanism: + +:: + + -object secret,id=3Dsecmaster,file=3Dmasterkey.data,format=3Dbase64 + + +In this case the ``masterkey.data`` file would be initialized with 32 +cryptographically secure random bytes, which are then base64 encoded. +The contents of this file will by used as an AES-256 key to encrypt the +real secret that can now be safely passed to QEMU inline as cipher text + +:: + + -object secret,id=3Dsecvnc0,keyid=3Dsecmaster,data=3DBASE64-CIPHERTEXT,= iv=3DBASE64-IV,format=3Dbase64 + + +In this example ``BASE64-CIPHERTEXT`` is the result of AES-256-CBC encrypt= ing +the secret with ``masterkey.data`` and then base64 encoding the ciphertext. +The ``BASE64-IV`` data is 16 random bytes which have been base64 encrypted. +These bytes are used as the initialization vector for the AES-256-CBC valu= e. + +A single master key can be used to encrypt all subsequent secrets, **but i= t is +critical that a different initialization vector is used for every secret**. + +Passing secrets via the Linux keyring +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The earlier mechanisms described are platform agnostic. If using QEMU on a= Linux +host, it is further possible to pass secrets to QEMU using the Linux keyri= ng: + +:: + + -object secret_keyring,id=3Dsecvnc0,serial=3D1729 + + +This instructs QEMU to load data from the Linux keyring secret identified = by +the serial number ``1729``. It is possible to combine use of the keyring w= ith +other features mentioned earlier such as base64 encoding: + +:: + + -object secret_keyring,id=3Dsecvnc0,serial=3D1729,format=3Dbase64 + + +and also encryption with a master key: + +:: + + -object secret_keyring,id=3Dsecvnc0,keyid=3Dsecmaster,serial=3D1729,iv= =3DBASE64-IV + + +Best practice +~~~~~~~~~~~~~ + +It is recommended for production deployments to use a master key secret, a= nd +then pass all subsequent inline secrets encrypted with the master key. + +Each QEMU instance must have a distinct master key, and that must be gener= ated +from a cryptographically secure random data source. The master key should = be +deleted immediately upon QEMU shutdown. If passing the master key as a fil= e, +the key file must have access control rules applied that restrict access to +just the one QEMU process that is intended to use it. Alternatively the Li= nux +keyring can be used to pass the master key to QEMU. + +The secrets for individual QEMU device backends must all then be encrypted +with this master key. + +This procedure helps ensure that the individual secrets for QEMU backends = will +not be compromised, even if ``-object`` CLI args or ``object_add`` monitor +commands are collected in log files and attached to public bug support tic= kets. +The only item that needs strongly protecting is the master key file. --=20 2.31.1 From nobody Sun May 12 13:56:57 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1621013804; cv=none; d=zohomail.com; s=zohoarc; b=WOohXNjpI+7pTAVLM2wglL+WgjRTGIzPVhXan0+fqYnuA3lVxz2rqyM66KnSOPCiGhw70fUTudWPhIaURTF3KBj4eIiu2XFS866yOwQN4R2KYNRYjxM84Yh5Whix5JX8ggJSpDCL1PFfHKWmpAcr+PmnVxCq9S6aUTATIwE7RRU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1621013804; h=Content-Type:Content-Transfer-Encoding:Cc: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=MHnAauViA++BlrmkjnlS4si5DQB1PSDQbJ2KtvEMB3U=; b=PM8cjH+4IwzUZx2o+qyk1aj+CxRYjMUfQLH2pYO7gQkHHwMQGmSnQh/UglgvQERe2O3l8gyhB3wokZAabT941ET9OtZQ8rXg40ZTPCz1R/mZPz6y5oQX/GGZyUxwW+BfccmQ+H8THiVx51S4IwKHq8I4dRNZRA2Epihnn+OScbQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1621013804058933.147485092106; Fri, 14 May 2021 10:36:44 -0700 (PDT) Received: from localhost ([::1]:33458 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhbjv-0003eM-0w for importer@patchew.org; Fri, 14 May 2021 13:36:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhbei-0002uV-3j for qemu-devel@nongnu.org; Fri, 14 May 2021 13:31:20 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:37630) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhbef-0007d7-On for qemu-devel@nongnu.org; Fri, 14 May 2021 13:31:19 -0400 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-392-anj3IghePpC7sgyT8Wq5rg-1; Fri, 14 May 2021 13:31:15 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4F03B9126B for ; Fri, 14 May 2021 17:31:14 +0000 (UTC) Received: from localhost.redhat.com (ovpn-113-212.ams2.redhat.com [10.36.113.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8DFEC5C1C4; Fri, 14 May 2021 17:31:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621013477; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MHnAauViA++BlrmkjnlS4si5DQB1PSDQbJ2KtvEMB3U=; b=R0nmMniXm0Yu50HXi5To30mE3Fh+KWexjzL+WZ1DACDf01mPXGyoB0Npc+zkEf52lZKMKG pBugmFpwtqG5Vc7Fbhqe0TKHM62SSsxGGTnxM1sw1m2Ne/NDBCiqqTi16jwDR8+GKVpF1c uSTB6GBw2yl1/SGhAyCM8Rg1xj254b8= X-MC-Unique: anj3IghePpC7sgyT8Wq5rg-1 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH 2/4] docs: document usage of the authorization framework Date: Fri, 14 May 2021 18:31:08 +0100 Message-Id: <20210514173110.1397741-3-berrange@redhat.com> In-Reply-To: <20210514173110.1397741-1-berrange@redhat.com> References: <20210514173110.1397741-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.699, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) The authorization framework provides a way to control access to network services after a client has been authenticated. This documents how to actually use it. Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Marc-Andr=C3=A9 Lureau --- docs/system/authz.rst | 263 ++++++++++++++++++++++++++++++++++++++++++ docs/system/index.rst | 1 + 2 files changed, 264 insertions(+) create mode 100644 docs/system/authz.rst diff --git a/docs/system/authz.rst b/docs/system/authz.rst new file mode 100644 index 0000000000..2276546d23 --- /dev/null +++ b/docs/system/authz.rst @@ -0,0 +1,263 @@ +.. _client authorization: + +Client authorization +-------------------- + +When configuring a QEMU network backend with either TLS certificates or SA= SL +authentication, access will be granted if the client successfully proves +their identity. If the authorization identity database is scoped to the QE= MU +client this may be sufficient. It is common, however, for the identity dat= abase +to be much broader and thus authentication alone does not enable sufficient +access control. In this case QEMU provides a flexible system for enforcing +finer grained authorization on clients post-authentication. + +Identity providers +~~~~~~~~~~~~~~~~~~ + +At the time of writing there are two authentication frameworks used by QEMU +that emit an identity upon completion. + + * TLS x509 certificate distinguished name. + + When configuring the QEMU backend as a network server with TLS, there + are a choice of credentials to use. The most common scenario is to util= ize + x509 certificates. The simplest configuration only involves issuing + certificates to the servers, allowing the client to avoid a MITM attack + against their intended server. + + It is possible, however, to enable mutual verification by requiring that + the client provide a certificate to the server to prove its own identit= y. + This is done by setting the property ``verify-peer=3Dyes`` on the + ``tls-creds-x509`` object, which is in fact the default. + + When peer verification is enabled, client will need to be issued with a + certificate by the same certificate authority as the server. If this is + still not sufficiently strong access control the Distinguished Name of + the certificate can be used as an identity in the QEMU authorization + framework. + + * SASL username. + + When configuring the QEMU backend as a network server with SASL, upon + completion of the SASL authentication mechanism, a username will be + provided. The format of this username will vary depending on the choice + of mechanism configured for SASL. It might be a simple UNIX style user + ``joebloggs``, while if using Kerberos/GSSAPI it can have a realm + attached ``joebloggs@QEMU.ORG``. Whatever format the username is prese= nted + in, it can be used with the QEMU authorization framework. + +Authorization drivers +~~~~~~~~~~~~~~~~~~~~~ + +The QEMU authorization framework is a general purpose design with choice of +user customizable drivers. These are provided as objects that can be +created at startup using the ``-object`` argument, or at runtime using the +``object_add`` monitor command. + +Simple +^^^^^^ + +This authorization driver provides a simple mechanism for granting access +based on an exact match against a single identity. This is useful when it = is +known that only a single client is to be allowed access. + +A possible use case would be when configuring QEMU for an incoming live +migration. It is known exactly which source QEMU the migration is expected +to arrive from. The x509 certificate associated with this source QEMU would +thus be used as the identity to match against. Alternatively if the virtual +machine is dedicated to a specific tenant, then the VNC server would be +configured with SASL and the username of only that tenant listed. + +To create an instance of this driver via QMP: + +:: + + { + "execute": "object-add", + "arguments": { + "qom-type": "authz-simple", + "id": "authz0", + "props": { + "identity": "fred" + } + } + } + + +Or via the command line + +:: + + -object authz-simple,id=3Dauthz0,identity=3Dfred + + +List +^^^^ + +In some network backends it will be desirable to grant access to a range of +clients. This authorization driver provides a list mechanism for granting +access by matching identities against a list of permitted one. Each match +rule has an associated policy and a catch all policy applies if no rule +matches. The match can either be done as an exact string comparison, or can +use the shell-like glob syntax, which allows for use of wildcards. + +To create an instance of this class via QMP: + +:: + + { + "execute": "object-add", + "arguments": { + "qom-type": "authz-list", + "id": "authz0", + "props": { + "rules": [ + { "match": "fred", "policy": "allow", "format": "exact" }, + { "match": "bob", "policy": "allow", "format": "exact" }, + { "match": "danb", "policy": "deny", "format": "exact" }, + { "match": "dan*", "policy": "allow", "format": "glob" } + ], + "policy": "deny" + } + } + } + + +Due to the way this driver requires setting nested properties, creating +it on the command line will require use of the JSON syntax for ``-object``. +In most cases, however, the next driver will be more suitable. + +List file +^^^^^^^^^ + +This is a variant on the previous driver that allows for a more dynamic +access control policy by storing the match rules in a standalone file +that can be reloaded automatically upon change. + +To create an instance of this class via QMP: + +:: + + { + "execute": "object-add", + "arguments": { + "qom-type": "authz-list-file", + "id": "authz0", + "props": { + "filename": "/etc/qemu/myvm-vnc.acl", + "refresh": true + } + } + } + + +If ``refresh`` is ``yes``, inotify is used to monitor for changes +to the file and auto-reload the rules. + +The ``myvm-vnc.acl`` file should contain the match rules in a format that +closely matches the previous driver: + +:: + + { + "rules": [ + { "match": "fred", "policy": "allow", "format": "exact" }, + { "match": "bob", "policy": "allow", "format": "exact" }, + { "match": "danb", "policy": "deny", "format": "exact" }, + { "match": "dan*", "policy": "allow", "format": "glob" } + ], + "policy": "deny" + } + + +The object can be created on the command line using + +:: + + -object authz-list-file,id=3Dauthz0,\ + filename=3D/etc/qemu/myvm-vnc.acl,refresh=3Don + + +PAM +^^^ + +In some scenarios it might be desirable to integrate with authorization +mechanisms that are implemented outside of QEMU. In order to allow maximum +flexibility, QEMU provides a driver that uses the ``PAM`` framework. + +To create an instance of this class via QMP: + +:: + + { + "execute": "object-add", + "arguments": { + "qom-type": "authz-pam", + "id": "authz0", + "parameters": { + "service": "qemu-vnc-tls" + } + } + } + + +The driver only uses the PAM "account" verification +subsystem. The above config would require a config +file /etc/pam.d/qemu-vnc-tls. For a simple file +lookup it would contain + +:: + + account requisite pam_listfile.so item=3Duser sense=3Dallow \ + file=3D/etc/qemu/vnc.allow + + +The external file would then contain a list of usernames. +If x509 cert was being used as the username, a suitable +entry would match the distinguished name: + +:: + + CN=3Dlaptop.berrange.com,O=3DBerrange Home,L=3DLondon,ST=3DLondon,C=3DGB + + +On the command line it can be created using + +:: + + -object authz-pam,id=3Dauthz0,service=3Dqemu-vnc-tls + + +There are a variety of PAM plugins that can be used which are not illustra= ted +here, and it is possible to implement brand new plugins using the PAM API. + + +Connecting backends +~~~~~~~~~~~~~~~~~~~ + +The authorization driver is created using the ``-object`` argument and then +needs to be associated with a network service. The authorization driver ob= ject +will be given a unique ID that needs to be referenced. + +The property to set in the network service will vary depending on the type= of +identity to verify. By convention, any network server backend that uses TLS +will provide ``tls-authz`` property, while any server using SASL will prov= ide +a ``sasl-authz`` property. + +Thus a example using SASL and authorization for the VNC server would look +like: + +:: + + $QEMU --object authz-simple,id=3Dauthz0,identity=3Dfred \ + --vnc 0.0.0.0:1,sasl,sasl-authz=3Dauthz0 + +While to validate both the x509 certificate and SASL username: + +:: + + echo "CN=3Dlaptop.qemu.org,O=3DQEMU Project,L=3DLondon,ST=3DLondon,C=3D= GB" >> tls.acl + $QEMU --object authz-simple,id=3Dauthz0,identity=3Dfred \ + --object authz-list-file,id=3Dauthz1,filename=3Dtls.acl \ + --object tls-creds-x509,id=3Dtls0,dir=3D/etc/qemu/tls,verify-peer=3Dyes \ + --vnc 0.0.0.0:1,sasl,sasl-authz=3Dauth0,tls-creds=3Dtls0,tls-auth= z=3Dauthz1 diff --git a/docs/system/index.rst b/docs/system/index.rst index 6aa2f8c05c..6092eb2d91 100644 --- a/docs/system/index.rst +++ b/docs/system/index.rst @@ -31,6 +31,7 @@ Contents: vnc-security tls secrets + authz gdb managed-startup cpu-hotplug --=20 2.31.1 From nobody Sun May 12 13:56:57 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1621013799; cv=none; d=zohomail.com; s=zohoarc; b=A4GwxCZQ1BMpO42L6fvisGBcWDA+ro9152sJDtv/CpRbktdyzw14VzwQgeAuCcTkqSFrLkUaZJ3kOD7aub+OhO2epOMOVWm3YWmzteuzCPsfBBiYoTFWGHBAi6w5pbcfsdKLGOVltkdTDEkGNr8GBurr1OpBHZxcs3ITkHhhOps= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1621013799; h=Content-Type:Content-Transfer-Encoding:Cc: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=i0AqscuC0sCHNdnaq7GsvzkwtZ9TuDvo49dEJAQy1xE=; b=SyLcvev5L/96AqKq/cNqicYMxDeW6Y91ZSynKYXYDhtscr7y7wY/RDynGfP/x876h9GatRmV/XQc8AiLT1qrRr2hm1VhTLvJSKLImKxDLaMZmq9jZ2pRg1cuZt++UV1Zbm6Lu0RxjuhtYpSBG9Qo95hYkHDq3Zt5bDEdHswLN24= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1621013799988608.7809445796114; Fri, 14 May 2021 10:36:39 -0700 (PDT) Received: from localhost ([::1]:33248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhbjr-0003Vs-0a for importer@patchew.org; Fri, 14 May 2021 13:36:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhbei-0002vG-B4 for qemu-devel@nongnu.org; Fri, 14 May 2021 13:31:20 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:53898) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhbeg-0007ek-Jb for qemu-devel@nongnu.org; Fri, 14 May 2021 13:31:20 -0400 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-385-lrImU6OTM3mJXhWmfqg0dw-1; Fri, 14 May 2021 13:31:16 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6E17118BA280 for ; Fri, 14 May 2021 17:31:15 +0000 (UTC) Received: from localhost.redhat.com (ovpn-113-212.ams2.redhat.com [10.36.113.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id ACAF45C1C4; Fri, 14 May 2021 17:31:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621013478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=i0AqscuC0sCHNdnaq7GsvzkwtZ9TuDvo49dEJAQy1xE=; b=Jn8z4hFUxc9i8QnFuwRZrZNzKrNjhkOvd/ExWnL7tL4jf9JmtmqQQBivkZUlk1pksCugmg gCEkF82/veJcyk6jX2qLUw3oI4EZWuWB+XjzMYlfwzx8lQO29b7jrrgv+WaUhpuFyW8aYQ Gs3262/gof/EddYPxQlqdCf0elHS10k= X-MC-Unique: lrImU6OTM3mJXhWmfqg0dw-1 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH 3/4] docs: recommend SCRAM-SHA-256 SASL mech instead of SHA-1 variant Date: Fri, 14 May 2021 18:31:09 +0100 Message-Id: <20210514173110.1397741-4-berrange@redhat.com> In-Reply-To: <20210514173110.1397741-1-berrange@redhat.com> References: <20210514173110.1397741-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.699, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) The SHA-256 variant better meats modern security expectations. Also warn that the password file is storing entries in clear text. Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Marc-Andr=C3=A9 Lureau --- docs/system/vnc-security.rst | 7 ++++--- qemu.sasl | 11 ++++++----- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/docs/system/vnc-security.rst b/docs/system/vnc-security.rst index 830f6acc73..4c1769eeb8 100644 --- a/docs/system/vnc-security.rst +++ b/docs/system/vnc-security.rst @@ -168,7 +168,7 @@ used is drastically reduced. In fact only the GSSAPI SA= SL mechanism provides an acceptable level of security by modern standards. Previous versions of QEMU referred to the DIGEST-MD5 mechanism, however, it has multiple serious flaws described in detail in RFC 6331 and thus should -never be used any more. The SCRAM-SHA-1 mechanism provides a simple +never be used any more. The SCRAM-SHA-256 mechanism provides a simple username/password auth facility similar to DIGEST-MD5, but does not support session encryption, so can only be used in combination with TLS. =20 @@ -191,11 +191,12 @@ reasonable configuration is =20 :: =20 - mech_list: scram-sha-1 + mech_list: scram-sha-256 sasldb_path: /etc/qemu/passwd.db =20 The ``saslpasswd2`` program can be used to populate the ``passwd.db`` -file with accounts. +file with accounts. Note that the ``passwd.db`` file stores passwords +in clear text. =20 Other SASL configurations will be left as an exercise for the reader. Note that all mechanisms, except GSSAPI, should be combined with use of diff --git a/qemu.sasl b/qemu.sasl index fb8a92ba58..abdfc686be 100644 --- a/qemu.sasl +++ b/qemu.sasl @@ -19,15 +19,15 @@ mech_list: gssapi =20 # 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 +# '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, and the VNC server will # negotiate which to use by considering the list enabled on the VNC # client. -#mech_list: scram-sha-1 gssapi +#mech_list: scram-sha-256 gssapi =20 # Some older builds of MIT kerberos on Linux ignore this option & # instead need KRB5_KTNAME env var. @@ -38,7 +38,8 @@ mech_list: gssapi # mechanism this can be commented out. keytab: /etc/qemu/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 qemu [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/qemu/passwd.db --=20 2.31.1 From nobody Sun May 12 13:56:57 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1621014094; cv=none; d=zohomail.com; s=zohoarc; b=D4gZaj8hdihM3GkT0HP0uHoxBRoLPEx/KxyrFQqfLK4JEvnkY8s/9mmM2pc0DPIXF8gpYFn/KLpOrYeFGlk5cDrElsFnLu3SxZIOdAYMrv4EHEgkIzUGMt7S/uqdTVREfFM0KOK89Tw8Hr9JLhaUK3iKe7sUtxpMbnh4JJlhIvU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1621014094; h=Content-Type:Content-Transfer-Encoding:Cc: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=OgaKi3bqPUSyL/e/XvADdG5dMLoIT+LVwi6y9+nRWdo=; b=PM6nS21UeI/Jopkicq19onaMXgrK9D0FUQT4AvnMPnajVMKTbo63rKMB9GnI7Wo4qocnw38cXzjrkOvRZ0va+A261xcCVyqiknS+uJ3O3oBC7toXBWncNTD3uEzEB6a2FeHaiiEMe8TL5GU1hanFu19QDgqX4/+QdmjC3/2BwhY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1621014094826575.4909259200836; Fri, 14 May 2021 10:41:34 -0700 (PDT) Received: from localhost ([::1]:41846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhbob-0000uy-CA for importer@patchew.org; Fri, 14 May 2021 13:41:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhbei-0002xY-Vm for qemu-devel@nongnu.org; Fri, 14 May 2021 13:31:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:54193) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhbeh-0007ev-D9 for qemu-devel@nongnu.org; Fri, 14 May 2021 13:31:20 -0400 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-294-hW9Z8mDVNB2rwysIh43brw-1; Fri, 14 May 2021 13:31:17 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 74B19801817 for ; Fri, 14 May 2021 17:31:16 +0000 (UTC) Received: from localhost.redhat.com (ovpn-113-212.ams2.redhat.com [10.36.113.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id CB41B5C1C4; Fri, 14 May 2021 17:31:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621013478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OgaKi3bqPUSyL/e/XvADdG5dMLoIT+LVwi6y9+nRWdo=; b=Hwyp6veMX5dRzZpPQvScpcV+hjs6LzvU3PdEayrSbMz2P/U+ubl+IopdzDOmXlJSaDzAOY mgHezEQmCZmriigmjgY377pCNSFB3AcUCFD+KtvUSeT28G4DX2DY8JkvWIzOFpweg/+sZJ yKdQieRaolujSnrCSdkfZ5JbU+w7cwk= X-MC-Unique: hW9Z8mDVNB2rwysIh43brw-1 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH 4/4] sasl: remove comment about obsolete kerberos versions Date: Fri, 14 May 2021 18:31:10 +0100 Message-Id: <20210514173110.1397741-5-berrange@redhat.com> In-Reply-To: <20210514173110.1397741-1-berrange@redhat.com> References: <20210514173110.1397741-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.699, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) This is not relevant to any OS distro that QEMU currently targets. Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Marc-Andr=C3=A9 Lureau --- qemu.sasl | 4 ---- 1 file changed, 4 deletions(-) diff --git a/qemu.sasl b/qemu.sasl index abdfc686be..851acc7e8f 100644 --- a/qemu.sasl +++ b/qemu.sasl @@ -29,10 +29,6 @@ mech_list: gssapi # client. #mech_list: scram-sha-256 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 -# # 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. --=20 2.31.1