summaryrefslogtreecommitdiff
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.sasl
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.sasl')
-rw-r--r--qemu.sasl34
1 files changed, 34 insertions, 0 deletions
diff --git a/qemu.sasl b/qemu.sasl
new file mode 100644
index 000000000..cf19cf8d0
--- /dev/null
+++ b/qemu.sasl
@@ -0,0 +1,34 @@
+# If you want to use the non-TLS socket, then you *must* include
+# the GSSAPI or DIGEST-MD5 mechanisms, because they are the only
+# ones that can offer session encryption as well as authentication.
+#
+# If you're only using TLS, then you can turn on any mechanisms
+# you like for authentication, because TLS provides the encryption
+#
+# Default to a simple username+password mechanism
+# NB digest-md5 is no longer considered secure by current standards
+mech_list: digest-md5
+
+# Before you can use GSSAPI, you need a service principle on the
+# KDC server for libvirt, and that to be exported to the keytab
+# file listed below
+#mech_list: gssapi
+#
+# You can also list many mechanisms at once, then the user can choose
+# by adding '?auth=sasl.gssapi' to their libvirt URI, eg
+# qemu+tcp://hostname/system?auth=sasl.gssapi
+#mech_list: digest-md5 gssapi
+
+# 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
+keytab: /etc/qemu/krb5.tab
+
+# If using digest-md5 for username/passwds, then this is the file
+# containing the passwds. Use 'saslpasswd2 -a qemu [username]'
+# to add entries, and 'sasldblistusers2 -a qemu' to browse it
+sasldb_path: /etc/qemu/passwd.db
+
+
+auxprop_plugin: sasldb
+