qemu/vnc.h

320 lines
9.5 KiB
C
Raw Normal View History

/*
* QEMU VNC display driver
*
* Copyright (C) 2006 Anthony Liguori <anthony@codemonkey.ws>
* Copyright (C) 2006 Fabrice Bellard
* Copyright (C) 2009 Red Hat, Inc
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#ifndef __QEMU_VNC_H
#define __QEMU_VNC_H
#include "qemu-common.h"
#include "console.h"
#include "monitor.h"
#include "audio/audio.h"
#include <zlib.h>
#include "keymaps.h"
Move TLS auth into separate file ("Daniel P. Berrange") This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 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@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:23 +03:00
// #define _VNC_DEBUG 1
#ifdef _VNC_DEBUG
#define VNC_DEBUG(fmt, ...) do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
#else
#define VNC_DEBUG(fmt, ...) do { } while (0)
#endif
/*****************************************************************************
*
* Core data structures
*
*****************************************************************************/
typedef struct Buffer
{
size_t capacity;
size_t offset;
uint8_t *buffer;
} Buffer;
typedef struct VncState VncState;
typedef int VncReadEvent(VncState *vs, uint8_t *data, size_t len);
typedef void VncWritePixels(VncState *vs, void *data, int size);
typedef void VncSendHextileTile(VncState *vs,
int x, int y, int w, int h,
void *last_bg,
void *last_fg,
int *has_bg, int *has_fg);
#define VNC_MAX_WIDTH 2048
#define VNC_MAX_HEIGHT 2048
#define VNC_DIRTY_WORDS (VNC_MAX_WIDTH / (16 * 32))
#define VNC_AUTH_CHALLENGE_SIZE 16
typedef struct VncDisplay VncDisplay;
Move TLS auth into separate file ("Daniel P. Berrange") This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 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@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:23 +03:00
#ifdef CONFIG_VNC_TLS
#include "vnc-tls.h"
#include "vnc-auth-vencrypt.h"
#endif
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
2009-03-06 23:27:28 +03:00
#ifdef CONFIG_VNC_SASL
#include "vnc-auth-sasl.h"
#endif
Move TLS auth into separate file ("Daniel P. Berrange") This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 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@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:23 +03:00
struct VncDisplay
{
int lsock;
DisplayState *ds;
VncState *clients;
kbd_layout_t *kbd_layout;
char *display;
char *password;
int auth;
#ifdef CONFIG_VNC_TLS
Move TLS auth into separate file ("Daniel P. Berrange") This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 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@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:23 +03:00
int subauth; /* Used by VeNCrypt */
VncDisplayTLS tls;
#endif
Support ACLs for controlling VNC access ("Daniel P. Berrange") This patch introduces a generic internal API for access control lists to be used by network servers in QEMU. It adds support for checking these ACL in the VNC server, in two places. The first ACL is for the SASL authentication mechanism, checking the SASL username. This ACL is called 'vnc.username'. The second is for the TLS authentication mechanism, when x509 client certificates are turned on, checking against the Distinguished Name of the client. This ACL is called 'vnc.x509dname' The internal API provides for an ACL with the following characteristics - A unique name, eg vnc.username, and vnc.x509dname. - A default policy, allow or deny - An ordered series of match rules, with allow or deny policy If none of the match rules apply, then the default policy is used. There is a monitor API to manipulate the ACLs, which I'll describe via examples (qemu) acl show vnc.username policy: allow (qemu) acl policy vnc.username denya acl: policy set to 'deny' (qemu) acl allow vnc.username fred acl: added rule at position 1 (qemu) acl allow vnc.username bob acl: added rule at position 2 (qemu) acl allow vnc.username joe 1 acl: added rule at position 1 (qemu) acl show vnc.username policy: deny 0: allow fred 1: allow joe 2: allow bob (qemu) acl show vnc.x509dname policy: allow (qemu) acl policy vnc.x509dname deny acl: policy set to 'deny' (qemu) acl allow vnc.x509dname C=GB,O=ACME,L=London,CN=* acl: added rule at position 1 (qemu) acl allow vnc.x509dname C=GB,O=ACME,L=Boston,CN=bob acl: added rule at position 2 (qemu) acl show vnc.x509dname policy: deny 0: allow C=GB,O=ACME,L=London,CN=* 1: allow C=GB,O=ACME,L=Boston,CN=bob By default the VNC server will not use any ACLs, allowing access to the server if the user successfully authenticates. To enable use of ACLs to restrict user access, the ',acl' flag should be given when starting QEMU. The initial ACL activated will be a 'deny all' policy and should be customized using monitor commands. eg enable SASL auth and ACLs qemu .... -vnc localhost:1,sasl,acl The next patch will provide a way to load a pre-defined ACL when starting up Makefile | 6 + b/acl.c | 185 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ b/acl.h | 74 ++++++++++++++++++++++ configure | 18 +++++ monitor.c | 95 ++++++++++++++++++++++++++++ qemu-doc.texi | 49 ++++++++++++++ vnc-auth-sasl.c | 16 +++- vnc-auth-sasl.h | 7 ++ vnc-tls.c | 19 +++++ vnc-tls.h | 3 vnc.c | 21 ++++++ vnc.h | 3 12 files changed, 491 insertions(+), 5 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@6726 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:37 +03:00
#ifdef CONFIG_VNC_SASL
VncDisplaySASL sasl;
#endif
};
vnc: cleanup surface handling, fix screen corruption bug. (Gerd Hoffmann) This patch killes the old_data hack in the qemu server and replaces it with a clean separation of the guest-visible display surface and the vnc server display surface. Both guest and server surface have their own dirty bitmap for tracking screen updates. Workflow is this: (1) The guest writes to the guest surface. With shared buffers being active the guest writes are directly visible to the vnc server code. Note that this may happen in parallel to the vnc server code running (today only in xenfb, once we have vcpu threads in qemu also for other display adapters). (2) vnc_update() callback tags the specified area in the guest dirty map. (3) vnc_update_client() will first walk through the guest dirty map. It will compare guest and server surface for all regions tagged dirty and in case the screen content really did change the server surface and dirty map are updated. Note: old code used old_data in a simliar way, so this does *not* introduce an extra memcpy. (4) Then vnc_update_cient() will send the updates to the vnc client using the server surface and dirty map. Note: old code used the guest-visible surface instead, causing screen corruption in case of guest screen updates running in parallel. The separate dirty bitmap also has the nice effect that forced screen updates can be done cleanly by simply tagging the area in both guest and server dirty map. The old, hackish way was memset(old_data, 42, size) to trick the code checking for screen changes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6860 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-20 18:59:14 +03:00
struct VncSurface
{
uint32_t dirty[VNC_MAX_HEIGHT][VNC_DIRTY_WORDS];
DisplaySurface *ds;
};
struct VncState
{
QEMUTimer *timer;
int csock;
vnc: cleanup surface handling, fix screen corruption bug. (Gerd Hoffmann) This patch killes the old_data hack in the qemu server and replaces it with a clean separation of the guest-visible display surface and the vnc server display surface. Both guest and server surface have their own dirty bitmap for tracking screen updates. Workflow is this: (1) The guest writes to the guest surface. With shared buffers being active the guest writes are directly visible to the vnc server code. Note that this may happen in parallel to the vnc server code running (today only in xenfb, once we have vcpu threads in qemu also for other display adapters). (2) vnc_update() callback tags the specified area in the guest dirty map. (3) vnc_update_client() will first walk through the guest dirty map. It will compare guest and server surface for all regions tagged dirty and in case the screen content really did change the server surface and dirty map are updated. Note: old code used old_data in a simliar way, so this does *not* introduce an extra memcpy. (4) Then vnc_update_cient() will send the updates to the vnc client using the server surface and dirty map. Note: old code used the guest-visible surface instead, causing screen corruption in case of guest screen updates running in parallel. The separate dirty bitmap also has the nice effect that forced screen updates can be done cleanly by simply tagging the area in both guest and server dirty map. The old, hackish way was memset(old_data, 42, size) to trick the code checking for screen changes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6860 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-20 18:59:14 +03:00
DisplayState *ds;
vnc: cleanup surface handling, fix screen corruption bug. (Gerd Hoffmann) This patch killes the old_data hack in the qemu server and replaces it with a clean separation of the guest-visible display surface and the vnc server display surface. Both guest and server surface have their own dirty bitmap for tracking screen updates. Workflow is this: (1) The guest writes to the guest surface. With shared buffers being active the guest writes are directly visible to the vnc server code. Note that this may happen in parallel to the vnc server code running (today only in xenfb, once we have vcpu threads in qemu also for other display adapters). (2) vnc_update() callback tags the specified area in the guest dirty map. (3) vnc_update_client() will first walk through the guest dirty map. It will compare guest and server surface for all regions tagged dirty and in case the screen content really did change the server surface and dirty map are updated. Note: old code used old_data in a simliar way, so this does *not* introduce an extra memcpy. (4) Then vnc_update_cient() will send the updates to the vnc client using the server surface and dirty map. Note: old code used the guest-visible surface instead, causing screen corruption in case of guest screen updates running in parallel. The separate dirty bitmap also has the nice effect that forced screen updates can be done cleanly by simply tagging the area in both guest and server dirty map. The old, hackish way was memset(old_data, 42, size) to trick the code checking for screen changes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6860 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-20 18:59:14 +03:00
struct VncSurface guest; /* guest visible surface (aka ds->surface) */
struct VncSurface server; /* vnc server surface */
VncDisplay *vd;
int need_update;
int force_update;
uint32_t features;
int absolute;
int last_x;
int last_y;
uint32_t vnc_encoding;
uint8_t tight_quality;
uint8_t tight_compression;
int major;
int minor;
char challenge[VNC_AUTH_CHALLENGE_SIZE];
#ifdef CONFIG_VNC_TLS
Move TLS auth into separate file ("Daniel P. Berrange") This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 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@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:23 +03:00
VncStateTLS tls;
#endif
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
2009-03-06 23:27:28 +03:00
#ifdef CONFIG_VNC_SASL
VncStateSASL sasl;
#endif
Buffer output;
Buffer input;
/* current output mode information */
VncWritePixels *write_pixels;
VncSendHextileTile *send_hextile_tile;
vnc: cleanup surface handling, fix screen corruption bug. (Gerd Hoffmann) This patch killes the old_data hack in the qemu server and replaces it with a clean separation of the guest-visible display surface and the vnc server display surface. Both guest and server surface have their own dirty bitmap for tracking screen updates. Workflow is this: (1) The guest writes to the guest surface. With shared buffers being active the guest writes are directly visible to the vnc server code. Note that this may happen in parallel to the vnc server code running (today only in xenfb, once we have vcpu threads in qemu also for other display adapters). (2) vnc_update() callback tags the specified area in the guest dirty map. (3) vnc_update_client() will first walk through the guest dirty map. It will compare guest and server surface for all regions tagged dirty and in case the screen content really did change the server surface and dirty map are updated. Note: old code used old_data in a simliar way, so this does *not* introduce an extra memcpy. (4) Then vnc_update_cient() will send the updates to the vnc client using the server surface and dirty map. Note: old code used the guest-visible surface instead, causing screen corruption in case of guest screen updates running in parallel. The separate dirty bitmap also has the nice effect that forced screen updates can be done cleanly by simply tagging the area in both guest and server dirty map. The old, hackish way was memset(old_data, 42, size) to trick the code checking for screen changes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6860 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-20 18:59:14 +03:00
DisplaySurface clientds;
CaptureVoiceOut *audio_cap;
struct audsettings as;
VncReadEvent *read_handler;
size_t read_handler_expect;
/* input */
uint8_t modifiers_state[256];
Buffer zlib;
Buffer zlib_tmp;
z_stream zlib_stream[4];
VncState *next;
};
/*****************************************************************************
*
* Authentication modes
*
*****************************************************************************/
enum {
VNC_AUTH_INVALID = 0,
VNC_AUTH_NONE = 1,
VNC_AUTH_VNC = 2,
VNC_AUTH_RA2 = 5,
VNC_AUTH_RA2NE = 6,
VNC_AUTH_TIGHT = 16,
VNC_AUTH_ULTRA = 17,
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
2009-03-06 23:27:28 +03:00
VNC_AUTH_TLS = 18, /* Supported in GTK-VNC & VINO */
VNC_AUTH_VENCRYPT = 19, /* Supported in GTK-VNC & VeNCrypt */
VNC_AUTH_SASL = 20, /* Supported in GTK-VNC & VINO */
};
enum {
VNC_AUTH_VENCRYPT_PLAIN = 256,
VNC_AUTH_VENCRYPT_TLSNONE = 257,
VNC_AUTH_VENCRYPT_TLSVNC = 258,
VNC_AUTH_VENCRYPT_TLSPLAIN = 259,
VNC_AUTH_VENCRYPT_X509NONE = 260,
VNC_AUTH_VENCRYPT_X509VNC = 261,
VNC_AUTH_VENCRYPT_X509PLAIN = 262,
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
2009-03-06 23:27:28 +03:00
VNC_AUTH_VENCRYPT_X509SASL = 263,
VNC_AUTH_VENCRYPT_TLSSASL = 264,
};
/*****************************************************************************
*
* Encoding types
*
*****************************************************************************/
#define VNC_ENCODING_RAW 0x00000000
#define VNC_ENCODING_COPYRECT 0x00000001
#define VNC_ENCODING_RRE 0x00000002
#define VNC_ENCODING_CORRE 0x00000004
#define VNC_ENCODING_HEXTILE 0x00000005
#define VNC_ENCODING_ZLIB 0x00000006
#define VNC_ENCODING_TIGHT 0x00000007
#define VNC_ENCODING_ZLIBHEX 0x00000008
#define VNC_ENCODING_TRLE 0x0000000f
#define VNC_ENCODING_ZRLE 0x00000010
#define VNC_ENCODING_ZYWRLE 0x00000011
#define VNC_ENCODING_COMPRESSLEVEL0 0xFFFFFF00 /* -256 */
#define VNC_ENCODING_QUALITYLEVEL0 0xFFFFFFE0 /* -32 */
#define VNC_ENCODING_XCURSOR 0xFFFFFF10 /* -240 */
#define VNC_ENCODING_RICH_CURSOR 0xFFFFFF11 /* -239 */
#define VNC_ENCODING_POINTER_POS 0xFFFFFF18 /* -232 */
#define VNC_ENCODING_LASTRECT 0xFFFFFF20 /* -224 */
#define VNC_ENCODING_DESKTOPRESIZE 0xFFFFFF21 /* -223 */
#define VNC_ENCODING_POINTER_TYPE_CHANGE 0XFFFFFEFF /* -257 */
#define VNC_ENCODING_EXT_KEY_EVENT 0XFFFFFEFE /* -258 */
#define VNC_ENCODING_AUDIO 0XFFFFFEFD /* -259 */
#define VNC_ENCODING_WMVi 0x574D5669
/*****************************************************************************
*
* Other tight constants
*
*****************************************************************************/
/*
* Vendors known by TightVNC: standard VNC/RealVNC, TridiaVNC, and TightVNC.
*/
#define VNC_TIGHT_CCB_RESET_MASK (0x0f)
#define VNC_TIGHT_CCB_TYPE_MASK (0x0f << 4)
#define VNC_TIGHT_CCB_TYPE_FILL (0x08 << 4)
#define VNC_TIGHT_CCB_TYPE_JPEG (0x09 << 4)
#define VNC_TIGHT_CCB_BASIC_MAX (0x07 << 4)
#define VNC_TIGHT_CCB_BASIC_ZLIB (0x03 << 4)
#define VNC_TIGHT_CCB_BASIC_FILTER (0x04 << 4)
/*****************************************************************************
*
* Features
*
*****************************************************************************/
#define VNC_FEATURE_RESIZE 0
#define VNC_FEATURE_HEXTILE 1
#define VNC_FEATURE_POINTER_TYPE_CHANGE 2
#define VNC_FEATURE_WMVI 3
#define VNC_FEATURE_TIGHT 4
#define VNC_FEATURE_ZLIB 5
#define VNC_FEATURE_COPYRECT 6
#define VNC_FEATURE_RESIZE_MASK (1 << VNC_FEATURE_RESIZE)
#define VNC_FEATURE_HEXTILE_MASK (1 << VNC_FEATURE_HEXTILE)
#define VNC_FEATURE_POINTER_TYPE_CHANGE_MASK (1 << VNC_FEATURE_POINTER_TYPE_CHANGE)
#define VNC_FEATURE_WMVI_MASK (1 << VNC_FEATURE_WMVI)
#define VNC_FEATURE_TIGHT_MASK (1 << VNC_FEATURE_TIGHT)
#define VNC_FEATURE_ZLIB_MASK (1 << VNC_FEATURE_ZLIB)
#define VNC_FEATURE_COPYRECT_MASK (1 << VNC_FEATURE_COPYRECT)
Move TLS auth into separate file ("Daniel P. Berrange") This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 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@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:23 +03:00
/*****************************************************************************
*
* Internal APIs
*
*****************************************************************************/
/* Event loop functions */
void vnc_client_read(void *opaque);
void vnc_client_write(void *opaque);
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
2009-03-06 23:27:28 +03:00
long vnc_client_read_buf(VncState *vs, uint8_t *data, size_t datalen);
long vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen);
Move TLS auth into separate file ("Daniel P. Berrange") This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 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@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:23 +03:00
/* Protocol I/O functions */
void vnc_write(VncState *vs, const void *data, size_t len);
void vnc_write_u32(VncState *vs, uint32_t value);
void vnc_write_s32(VncState *vs, int32_t value);
void vnc_write_u16(VncState *vs, uint16_t value);
void vnc_write_u8(VncState *vs, uint8_t value);
void vnc_flush(VncState *vs);
void vnc_read_when(VncState *vs, VncReadEvent *func, size_t expecting);
/* Buffer I/O functions */
uint8_t read_u8(uint8_t *data, size_t offset);
uint16_t read_u16(uint8_t *data, size_t offset);
int32_t read_s32(uint8_t *data, size_t offset);
uint32_t read_u32(uint8_t *data, size_t offset);
/* Protocol stage functions */
void vnc_client_error(VncState *vs);
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
2009-03-06 23:27:28 +03:00
int vnc_client_io_error(VncState *vs, int ret, int last_errno);
Move TLS auth into separate file ("Daniel P. Berrange") This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 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@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 23:27:23 +03:00
void start_client_init(VncState *vs);
void start_auth_vnc(VncState *vs);
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
2009-03-06 23:27:28 +03:00
/* Buffer management */
void buffer_reserve(Buffer *buffer, size_t len);
int buffer_empty(Buffer *buffer);
uint8_t *buffer_end(Buffer *buffer);
void buffer_reset(Buffer *buffer);
void buffer_append(Buffer *buffer, const void *data, size_t len);
/* Misc helpers */
char *vnc_socket_local_addr(const char *format, int fd);
char *vnc_socket_remote_addr(const char *format, int fd);
#endif /* __QEMU_VNC_H */