From 166310299a1e7824bbff17e1f016659d18b4a559 Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Tue, 20 Oct 2020 17:08:27 +0100 Subject: os: deprecate the -enable-fips option and QEMU's FIPS enforcement The -enable-fips option was added a long time ago to prevent the use of single DES when VNC when FIPS mode is enabled. It should never have been added, because apps are supposed to unconditionally honour FIPS mode based on the '/proc/sys/crypto/fips_enabled' file contents. In addition there is more to achieving FIPS compliance than merely blocking use of certain algorithms. Those algorithms which are used need to perform self-tests at runtime. QEMU's built-in cryptography provider has no support for self-tests, and neither does the nettle library. If QEMU is required to be used in a FIPS enabled host, then it must be built with the libgcrypt library enabled, which will unconditionally enforce FIPS compliance in any algorithm usage. Thus there is no need to keep either the -enable-fips option in QEMU, or QEMU's internal FIPS checking methods. Reviewed-by: John Snow Reviewed-by: Thomas Huth Signed-off-by: Daniel P. Berrangé --- docs/system/deprecated.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'docs') diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 9de663526a..6ac757ed9f 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -134,6 +134,18 @@ Boolean options such as ``share=on``/``share=off`` could be written in short form as ``share`` and ``noshare``. This is now deprecated and will cause a warning. +``--enable-fips`` (since 6.0) +''''''''''''''''''''''''''''' + +This option restricts usage of certain cryptographic algorithms when +the host is operating in FIPS mode. + +If FIPS compliance is required, QEMU should be built with the ``libgcrypt`` +library enabled as a cryptography provider. + +Neither the ``nettle`` library, or the built-in cryptography provider are +supported on FIPS enabled hosts. + QEMU Machine Protocol (QMP) commands ------------------------------------ -- cgit v1.2.3-55-g7522 From 4d7beeab38e6d2d242bcf110532ff6a9b03bd53d Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Wed, 4 Nov 2020 13:57:21 +0000 Subject: Prefer 'on' | 'off' over 'yes' | 'no' for bool options Update some docs and test cases to use 'on' | 'off' as the preferred value for bool options. Reviewed-by: Thomas Huth Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Daniel P. Berrangé --- docs/system/vnc-security.rst | 10 +++++----- include/authz/listfile.h | 2 +- qemu-options.hx | 4 ++-- tests/qemu-iotests/233 | 4 ++-- 4 files changed, 10 insertions(+), 10 deletions(-) (limited to 'docs') diff --git a/docs/system/vnc-security.rst b/docs/system/vnc-security.rst index 558e4faffc..ebca656d87 100644 --- a/docs/system/vnc-security.rst +++ b/docs/system/vnc-security.rst @@ -65,7 +65,7 @@ encrypted session. .. parsed-literal:: |qemu_system| [...OPTIONS...] \ - -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=no \ + -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=off \ -vnc :1,tls-creds=tls0 -monitor stdio In the above example ``/etc/pki/qemu`` should contain at least three @@ -84,12 +84,12 @@ connecting. The server will request that the client provide a certificate, which it will then validate against the CA certificate. This is a good choice if deploying in an environment with a private internal certificate authority. It uses the same syntax as previously, -but with ``verify-peer`` set to ``yes`` instead. +but with ``verify-peer`` set to ``on`` instead. .. parsed-literal:: |qemu_system| [...OPTIONS...] \ - -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ + -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=on \ -vnc :1,tls-creds=tls0 -monitor stdio .. _vnc_005fsec_005fcertificate_005fpw: @@ -103,7 +103,7 @@ authentication to provide two layers of authentication for clients. .. parsed-literal:: |qemu_system| [...OPTIONS...] \ - -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ + -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=on \ -vnc :1,tls-creds=tls0,password -monitor stdio (qemu) change vnc password Password: ******** @@ -145,7 +145,7 @@ x509 options: .. parsed-literal:: |qemu_system| [...OPTIONS...] \ - -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ + -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=on \ -vnc :1,tls-creds=tls0,sasl -monitor stdio .. _vnc_005fsetup_005fsasl: diff --git a/include/authz/listfile.h b/include/authz/listfile.h index 0a1e5bddd3..0b7fe72198 100644 --- a/include/authz/listfile.h +++ b/include/authz/listfile.h @@ -73,7 +73,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(QAuthZListFile, * The object can be created on the command line using * * -object authz-list-file,id=authz0,\ - * filename=/etc/qemu/myvm-vnc.acl,refresh=yes + * filename=/etc/qemu/myvm-vnc.acl,refresh=on * */ struct QAuthZListFile { diff --git a/qemu-options.hx b/qemu-options.hx index 9172d51659..d0410f0512 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -5027,7 +5027,7 @@ SRST Note the use of quotes due to the x509 distinguished name containing whitespace, and escaping of ','. - ``-object authz-listfile,id=id,filename=path,refresh=yes|no`` + ``-object authz-listfile,id=id,filename=path,refresh=on|off`` Create an authorization object that will control access to network services. @@ -5072,7 +5072,7 @@ SRST # |qemu_system| \\ ... \\ - -object authz-simple,id=auth0,filename=/etc/qemu/vnc-sasl.acl,refresh=yes \\ + -object authz-simple,id=auth0,filename=/etc/qemu/vnc-sasl.acl,refresh=on \\ ... ``-object authz-pam,id=id,service=string`` diff --git a/tests/qemu-iotests/233 b/tests/qemu-iotests/233 index 7ce5764903..da150cd27b 100755 --- a/tests/qemu-iotests/233 +++ b/tests/qemu-iotests/233 @@ -84,7 +84,7 @@ echo echo "== check plain client to TLS server fails ==" nbd_server_start_tcp_socket \ - --object tls-creds-x509,dir=${tls_dir}/server1,endpoint=server,id=tls0,verify-peer=yes \ + --object tls-creds-x509,dir=${tls_dir}/server1,endpoint=server,id=tls0,verify-peer=on \ --tls-creds tls0 \ -f $IMGFMT "$TEST_IMG" 2>> "$TEST_DIR/server.log" @@ -129,7 +129,7 @@ echo "== check TLS with authorization ==" nbd_server_stop nbd_server_start_tcp_socket \ - --object tls-creds-x509,dir=${tls_dir}/server1,endpoint=server,id=tls0,verify-peer=yes \ + --object tls-creds-x509,dir=${tls_dir}/server1,endpoint=server,id=tls0,verify-peer=on \ --object "authz-simple,id=authz0,identity=CN=localhost,, \ O=Cthulu Dark Lord Enterprises client1,,L=R'lyeh,,C=South Pacific" \ --tls-authz authz0 \ -- cgit v1.2.3-55-g7522 From e6e80fcfd6c478231ac8ef9d2ec647da860252b6 Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Thu, 17 Sep 2020 16:50:47 +0100 Subject: docs: simplify and clarify the platform support rules The distinction between short life and long life Linux distributions turned out to be redundant. They can both be covered in a simple way by noting support will target the current release, and the previous release for a period of two years or until its EOL. This rule can also apply to the other UNIX based distros, leaving only Windows needing a different set of rules. This also clarifies that Debian LTS is out of scope, because the LTS support is provided by a separate group from the main Debian maintainer team. Reviewed-by: Eduardo Habkost Reviewed-by: Thomas Huth Signed-off-by: Daniel P. Berrangé --- docs/system/build-platforms.rst | 63 +++++++++++++++-------------------------- 1 file changed, 23 insertions(+), 40 deletions(-) (limited to 'docs') diff --git a/docs/system/build-platforms.rst b/docs/system/build-platforms.rst index 9734eba2f1..692323609e 100644 --- a/docs/system/build-platforms.rst +++ b/docs/system/build-platforms.rst @@ -25,55 +25,38 @@ software in their distro, QEMU upstream code will not add explicit support for those backports, unless the feature is auto-detectable in a manner that works for the upstream releases too. -The Repology site https://repology.org is a useful resource to identify +The `Repology`_ site is a useful resource to identify currently shipped versions of software in various operating systems, though it does not cover all distros listed below. -Linux OS --------- +Linux OS, macOS, FreeBSD, NetBSD, OpenBSD +----------------------------------------- -For distributions with frequent, short-lifetime releases, the project -will aim to support all versions that are not end of life by their -respective vendors. For the purposes of identifying supported software -versions, the project will look at Fedora, Ubuntu, and openSUSE distros. -Other short- lifetime distros will be assumed to ship similar software -versions. +The project aims to support the most recent major version at all times. Support +for the previous major version will be dropped 2 years after the new major +version is released or when the vendor itself drops support, whichever comes +first. In this context, third-party efforts to extend the lifetime of a distro +are not considered, even when they are endorsed by the vendor (eg. Debian LTS). -For distributions with long-lifetime releases, the project will aim to -support the most recent major version at all times. Support for the -previous major version will be dropped 2 years after the new major -version is released, or when it reaches "end of life". For the purposes -of identifying supported software versions, the project will look at -RHEL, Debian, Ubuntu LTS, and SLES distros. Other long-lifetime distros -will be assumed to ship similar software versions. +For the purposes of identifying supported software versions available on Linux, +the project will look at CentOS, Debian, Fedora, openSUSE, RHEL, SLES and +Ubuntu LTS. Other distros will be assumed to ship similar software versions. -Windows -------- - -The project supports building with current versions of the MinGW -toolchain, hosted on Linux. - -macOS ------ +For FreeBSD and OpenBSD, decisions will be made based on the contents of the +respective ports repository, while NetBSD will use the pkgsrc repository. -The project supports building with the two most recent versions of -macOS, with the current Homebrew package set available. +For macOS, `HomeBrew`_ will be used, although `MacPorts`_ is expected to carry +similar versions. -FreeBSD +Windows ------- -The project aims to support all versions which are not end of -life. - -NetBSD ------- +The project supports building with current versions of the MinGW toolchain, +hosted on Linux (Debian/Fedora). -The project aims to support the most recent major version at all times. -Support for the previous major version will be dropped 2 years after the -new major version is released. - -OpenBSD -------- +The version of the Windows API that's currently targeted is Vista / Server +2008. -The project aims to support all versions which are not end of -life. +.. _HomeBrew: https://brew.sh/ +.. _MacPorts: https://www.macports.org/ +.. _Repology: https://repology.org/ -- cgit v1.2.3-55-g7522 From f029f9112257c9a0e669c2955e8ace21a96704c1 Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Fri, 27 Nov 2020 10:32:45 +0000 Subject: docs: fix missing backslash in certtool shell example Reviewed-by: Peter Maydell Signed-off-by: Daniel P. Berrangé --- docs/system/tls.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/system/tls.rst b/docs/system/tls.rst index dc2b94257f..b0973afe1b 100644 --- a/docs/system/tls.rst +++ b/docs/system/tls.rst @@ -64,7 +64,7 @@ interactive prompts from certtool:: cert_signing_key EOF # certtool --generate-self-signed \ - --load-privkey ca-key.pem + --load-privkey ca-key.pem \ --template ca.info \ --outfile ca-cert.pem -- cgit v1.2.3-55-g7522