riscv/qemu - qemu - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Daniel P. Berrangé	213de8a2fb	sasl: remove comment about obsolete kerberos versions This is not relevant to any OS distro that QEMU currently targets. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	5 years ago
Daniel P. Berrangé	e2bf32dfab	docs: recommend SCRAM-SHA-256 SASL mech instead of SHA-1 variant The SHA-256 variant better meats modern security expectations. Also warn that the password file is storing entries in clear text. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	5 years ago
Daniel P. Berrange	c6a9a9f575	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>	9 years ago
Laszlo Ersek	dfb3804d47	sasl: Avoid 'Could not find keytab file' in syslog The "keytab" specification in "qemu.sasl" only makes sense if "gssapi" is selected in "mech_list". Even if the latter is not done (ie. "gssapi" is not selected), the cyrus-sasl library tries to open the specified keytab file, although nothing has a use for it outside the gssapi backend. Since the default keytab file "/etc/qemu/krb5.tab" is usually absent, the cyrus-sasl library emits a warning to syslog at startup, which tends to annoy users (who didn't ask for gssapi in the first place). Comment out the keytab specification per default. "qemu-doc.texi" already correctly explains how to use "mech_list: gssapi" together with "keytab:". See also: - upstream libvirt commit fe772f24, - Red Hat Bugzilla <https://bugzilla.redhat.com/show_bug.cgi?id=1018434>. Signed-off-by: Laszlo Ersek <lersek@redhat.com> ACKed-By: Cole Robinson <crobinso@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	12 years ago
Cole Robinson	805695daf6	Fix command example in qemu.sasl sasldblistusers2 doesn't have a '-a' option Signed-off-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	13 years ago
aliguori	2f9606b373	Add SASL authentication support ("Daniel P. Berrange") This patch adds the new SASL authentication protocol to the VNC server. It is enabled by setting the 'sasl' flag when launching VNC. SASL can optionally provide encryption via its SSF layer, if a suitable mechanism is configured (eg, GSSAPI/Kerberos, or Digest-MD5). If an SSF layer is not available, then it should be combined with the x509 VNC authentication protocol which provides encryption. eg, if using GSSAPI qemu -vnc localhost:1,sasl eg if using TLS/x509 for encryption qemu -vnc localhost:1,sasl,tls,x509 By default the Cyrus SASL library will look for its configuration in the file /etc/sasl2/qemu.conf. For non-root users, this can be overridden by setting the SASL_CONF_PATH environment variable, eg to make it look in $HOME/.sasl2. NB unprivileged users may not have access to the full range of SASL mechanisms, since some of them require some administrative privileges to configure. The patch includes an example SASL configuration file which illustrates config for GSSAPI and Digest-MD5, though it should be noted that the latter is not really considered secure any more. Most of the SASL authentication code is located in a separate source file, vnc-auth-sasl.c. The main vnc.c file only contains minimal integration glue, specifically parsing of command line flags / setup, and calls to start the SASL auth process, to do encoding/decoding for data. There are several possible stacks for reading & writing of data, depending on the combo of VNC authentication methods in use - Clear. read/write straight to socket - TLS. read/write via GNUTLS helpers - SASL. encode/decode via SASL SSF layer, then read/write to socket - SASL+TLS. encode/decode via SASL SSF layer, then read/write via GNUTLS Hence, the vnc_client_read & vnc_client_write methods have been refactored a little. vnc_client_read: main entry point for reading, calls either - vnc_client_read_plain reading, with no intermediate decoding - vnc_client_read_sasl reading, with SASL SSF decoding These two methods, then call vnc_client_read_buf(). This decides whether to write to the socket directly or write via GNUTLS. The situation is the same for writing data. More extensive comments have been added in the code / patch. The vnc_client_read_sasl and vnc_client_write_sasl method implementations live in the separate vnc-auth-sasl.c file. The state required for the SASL auth mechanism is kept in a separate VncStateSASL struct, defined in vnc-auth-sasl.h and included in the main VncState. The configure script probes for SASL and automatically enables it if found, unless --disable-vnc-sasl was given to override it. Makefile \| 7 Makefile.target \| 5 b/qemu.sasl \| 34 ++ b/vnc-auth-sasl.c \| 626 ++++++++++++++++++++++++++++++++++++++++++++++++++++ b/vnc-auth-sasl.h \| 67 +++++ configure \| 34 ++ qemu-doc.texi \| 97 ++++++++ vnc-auth-vencrypt.c \| 12 vnc.c \| 249 ++++++++++++++++++-- vnc.h \| 31 ++ 10 files changed, 1129 insertions(+), 33 deletions(-) Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6724 c046a42c-6fe2-441c-8c8c-71466251a162	17 years ago