aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authoraliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>2009-03-06 20:27:28 +0000
committeraliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>2009-03-06 20:27:28 +0000
commit2f9606b3736c3be4dbd606c46525c7b770ced119 (patch)
treec68a38d8b691e5235f1f2afc833aae9fea961d8b /qemu-doc.texi
parentMove TLS auth into separate file ("Daniel P. Berrange") (diff)
downloadqemu-kvm-2f9606b3736c3be4dbd606c46525c7b770ced119.tar.gz
qemu-kvm-2f9606b3736c3be4dbd606c46525c7b770ced119.tar.bz2
qemu-kvm-2f9606b3736c3be4dbd606c46525c7b770ced119.zip
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
Diffstat (limited to 'qemu-doc.texi')
-rw-r--r--qemu-doc.texi97
1 files changed, 97 insertions, 0 deletions
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 616de48c0..1528f39cf 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -616,6 +616,21 @@ path following this option specifies where the x509 certificates are to
be loaded from. See the @ref{vnc_security} section for details on generating
certificates.
+@item sasl
+
+Require that the client use SASL to authenticate with the VNC server.
+The exact choice of authentication method used is controlled from the
+system / user's SASL configuration file for the 'qemu' service. This
+is typically found in /etc/sasl2/qemu.conf. If running QEMU as an
+unprivileged user, an environment variable SASL_CONF_PATH can be used
+to make it search alternate locations for the service config.
+While some SASL auth methods can also provide data encryption (eg GSSAPI),
+it is recommended that SASL always be combined with the 'tls' and
+'x509' settings to enable use of SSL and server certificates. This
+ensures a data encryption preventing compromise of authentication
+credentials. See the @ref{vnc_security} section for details on using
+SASL authentication.
+
@end table
@end table
@@ -2061,7 +2076,10 @@ considerations depending on the deployment scenarios.
* vnc_sec_certificate::
* vnc_sec_certificate_verify::
* vnc_sec_certificate_pw::
+* vnc_sec_sasl::
+* vnc_sec_certificate_sasl::
* vnc_generate_cert::
+* vnc_setup_sasl::
@end menu
@node vnc_sec_none
@subsection Without passwords
@@ -2144,6 +2162,41 @@ Password: ********
(qemu)
@end example
+
+@node vnc_sec_sasl
+@subsection With SASL authentication
+
+The SASL authentication method is a VNC extension, that provides an
+easily extendable, pluggable authentication method. This allows for
+integration with a wide range of authentication mechanisms, such as
+PAM, GSSAPI/Kerberos, LDAP, SQL databases, one-time keys and more.
+The strength of the authentication depends on the exact mechanism
+configured. If the chosen mechanism also provides a SSF layer, then
+it will encrypt the datastream as well.
+
+Refer to the later docs on how to choose the exact SASL mechanism
+used for authentication, but assuming use of one supporting SSF,
+then QEMU can be launched with:
+
+@example
+qemu [...OPTIONS...] -vnc :1,sasl -monitor stdio
+@end example
+
+@node vnc_sec_certificate_sasl
+@subsection With x509 certificates and SASL authentication
+
+If the desired SASL authentication mechanism does not supported
+SSF layers, then it is strongly advised to run it in combination
+with TLS and x509 certificates. This provides securely encrypted
+data stream, avoiding risk of compromising of the security
+credentials. This can be enabled, by combining the 'sasl' option
+with the aforementioned TLS + x509 options:
+
+@example
+qemu [...OPTIONS...] -vnc :1,tls,x509,sasl -monitor stdio
+@end example
+
+
@node vnc_generate_cert
@subsection Generating certificates for VNC
@@ -2255,6 +2308,50 @@ EOF
The @code{client-key.pem} and @code{client-cert.pem} files should now be securely
copied to the client for which they were generated.
+
+@node vnc_setup_sasl
+
+@subsection Configuring SASL mechanisms
+
+The following documentation assumes use of the Cyrus SASL implementation on a
+Linux host, but the principals should apply to any other SASL impl. When SASL
+is enabled, the mechanism configuration will be loaded from system default
+SASL service config /etc/sasl2/qemu.conf. If running QEMU as an
+unprivileged user, an environment variable SASL_CONF_PATH can be used
+to make it search alternate locations for the service config.
+
+The default configuration might contain
+
+@example
+mech_list: digest-md5
+sasldb_path: /etc/qemu/passwd.db
+@end example
+
+This says to use the 'Digest MD5' mechanism, which is similar to the HTTP
+Digest-MD5 mechanism. The list of valid usernames & passwords is maintained
+in the /etc/qemu/passwd.db file, and can be updated using the saslpasswd2
+command. While this mechanism is easy to configure and use, it is not
+considered secure by modern standards, so only suitable for developers /
+ad-hoc testing.
+
+A more serious deployment might use Kerberos, which is done with the 'gssapi'
+mechanism
+
+@example
+mech_list: gssapi
+keytab: /etc/qemu/krb5.tab
+@end example
+
+For this to work the administrator of your KDC must generate a Kerberos
+principal for the server, with a name of 'qemu/somehost.example.com@@EXAMPLE.COM'
+replacing 'somehost.example.com' with the fully qualified host name of the
+machine running QEMU, and 'EXAMPLE.COM' with the Keberos Realm.
+
+Other configurations will be left as an exercise for the reader. It should
+be noted that only Digest-MD5 and GSSAPI provides a SSF layer for data
+encryption. For all other mechanisms, VNC should always be configured to
+use TLS and x509 certificates to protect security credentials from snooping.
+
@node gdb_usage
@section GDB usage