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>

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>

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>

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>

sasldblistusers2 doesn't have a '-a' option

Signed-off-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

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