2009-03-06 21:27:13 +01:00
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2016-06-29 13:47:03 +02:00
|
|
|
#ifndef QEMU_VNC_H
|
|
|
|
#define QEMU_VNC_H
|
2009-03-06 21:27:13 +01:00
|
|
|
|
2012-12-17 18:20:00 +01:00
|
|
|
#include "qemu/queue.h"
|
|
|
|
#include "qemu/thread.h"
|
2012-11-28 12:06:30 +01:00
|
|
|
#include "ui/console.h"
|
2009-03-06 21:27:13 +01:00
|
|
|
#include "audio/audio.h"
|
2012-12-17 18:20:00 +01:00
|
|
|
#include "qemu/bitmap.h"
|
ui: convert VNC server to use QCryptoTLSSession
Switch VNC server over to using the QCryptoTLSSession object
for the TLS session. This removes the direct use of gnutls
from the VNC server code. It also removes most knowledge
about TLS certificate handling from the VNC server code.
This has the nice effect that all the CONFIG_VNC_TLS
conditionals go away and the user gets an actual error
message when requesting TLS instead of it being silently
ignored.
With this change, the existing configuration options for
enabling TLS with -vnc are deprecated.
Old syntax for anon-DH credentials:
-vnc hostname:0,tls
New syntax:
-object tls-creds-anon,id=tls0,endpoint=server \
-vnc hostname:0,tls-creds=tls0
Old syntax for x509 credentials, no client certs:
-vnc hostname:0,tls,x509=/path/to/certs
New syntax:
-object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \
-vnc hostname:0,tls-creds=tls0
Old syntax for x509 credentials, requiring client certs:
-vnc hostname:0,tls,x509verify=/path/to/certs
New syntax:
-object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \
-vnc hostname:0,tls-creds=tls0
This aligns VNC with the way TLS credentials are to be
configured in the future for chardev, nbd and migration
backends. It also has the benefit that the same TLS
credentials can be shared across multiple VNC server
instances, if desired.
If someone uses the deprecated syntax, it will internally
result in the creation of a 'tls-creds' object with an ID
based on the VNC server ID. This allows backwards compat
with the CLI syntax, while still deleting all the original
TLS code from the VNC server.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
|
|
|
#include "crypto/tlssession.h"
|
2015-03-03 18:13:42 +01:00
|
|
|
#include "qemu/buffer.h"
|
2015-02-27 17:20:57 +01:00
|
|
|
#include "io/channel-socket.h"
|
2015-03-02 20:01:05 +01:00
|
|
|
#include "io/channel-tls.h"
|
2018-02-01 17:45:14 +01:00
|
|
|
#include "io/net-listener.h"
|
2016-02-18 19:40:24 +01:00
|
|
|
#include "authz/base.h"
|
2009-03-06 21:27:13 +01:00
|
|
|
#include <zlib.h>
|
|
|
|
|
|
|
|
#include "keymaps.h"
|
2011-02-04 09:06:01 +01:00
|
|
|
#include "vnc-palette.h"
|
|
|
|
#include "vnc-enc-zrle.h"
|
2019-01-22 10:28:12 +01:00
|
|
|
#include "ui/kbd-state.h"
|
2009-03-06 21:27:13 +01:00
|
|
|
|
2009-03-06 21:27:23 +01: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
|
|
|
|
|
2009-03-06 21:27:13 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
*
|
|
|
|
* Core data structures
|
|
|
|
*
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
typedef struct VncState VncState;
|
2010-07-07 20:58:02 +02:00
|
|
|
typedef struct VncJob VncJob;
|
|
|
|
typedef struct VncRect VncRect;
|
|
|
|
typedef struct VncRectEntry VncRectEntry;
|
2009-03-06 21:27:13 +01:00
|
|
|
|
|
|
|
typedef int VncReadEvent(VncState *vs, uint8_t *data, size_t len);
|
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
typedef void VncWritePixels(VncState *vs, void *data, int size);
|
2009-03-06 21:27:13 +01:00
|
|
|
|
|
|
|
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);
|
|
|
|
|
2014-01-08 10:08:33 +01:00
|
|
|
/* VNC_DIRTY_PIXELS_PER_BIT is the number of dirty pixels represented
|
2014-06-30 10:57:51 +02:00
|
|
|
* by one bit in the dirty bitmap, should be a power of 2 */
|
2014-01-08 10:08:33 +01:00
|
|
|
#define VNC_DIRTY_PIXELS_PER_BIT 16
|
|
|
|
|
2014-06-30 10:57:51 +02:00
|
|
|
/* VNC_MAX_WIDTH must be a multiple of VNC_DIRTY_PIXELS_PER_BIT. */
|
|
|
|
|
|
|
|
#define VNC_MAX_WIDTH ROUND_UP(2560, VNC_DIRTY_PIXELS_PER_BIT)
|
|
|
|
#define VNC_MAX_HEIGHT 2048
|
|
|
|
|
2011-03-03 21:37:55 +01:00
|
|
|
/* VNC_DIRTY_BITS is the number of bits in the dirty bitmap. */
|
2014-01-08 10:08:33 +01:00
|
|
|
#define VNC_DIRTY_BITS (VNC_MAX_WIDTH / VNC_DIRTY_PIXELS_PER_BIT)
|
2009-03-06 21:27:13 +01:00
|
|
|
|
2014-01-08 10:08:35 +01:00
|
|
|
/* VNC_DIRTY_BPL (BPL = bits per line) might be greater than
|
|
|
|
* VNC_DIRTY_BITS due to alignment */
|
|
|
|
#define VNC_DIRTY_BPL(x) (sizeof((x)->dirty) / VNC_MAX_HEIGHT * BITS_PER_BYTE)
|
|
|
|
|
2011-02-04 09:05:55 +01:00
|
|
|
#define VNC_STAT_RECT 64
|
|
|
|
#define VNC_STAT_COLS (VNC_MAX_WIDTH / VNC_STAT_RECT)
|
|
|
|
#define VNC_STAT_ROWS (VNC_MAX_HEIGHT / VNC_STAT_RECT)
|
|
|
|
|
2009-03-06 21:27:13 +01:00
|
|
|
#define VNC_AUTH_CHALLENGE_SIZE 16
|
|
|
|
|
|
|
|
typedef struct VncDisplay VncDisplay;
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
#include "vnc-auth-vencrypt.h"
|
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 21:27:28 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
#include "vnc-auth-sasl.h"
|
|
|
|
#endif
|
2013-01-21 11:04:44 +01:00
|
|
|
#include "vnc-ws.h"
|
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 21:27:28 +01:00
|
|
|
|
2011-02-04 09:05:55 +01:00
|
|
|
struct VncRectStat
|
|
|
|
{
|
|
|
|
/* time of last 10 updates, to find update frequency */
|
|
|
|
struct timeval times[10];
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
double freq; /* Update frequency (in Hz) */
|
|
|
|
bool updated; /* Already updated during this refresh */
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef struct VncRectStat VncRectStat;
|
|
|
|
|
2009-08-03 11:54:32 +02:00
|
|
|
struct VncSurface
|
|
|
|
{
|
2011-02-04 09:05:55 +01:00
|
|
|
struct timeval last_freq_check;
|
2014-06-30 10:57:51 +02:00
|
|
|
DECLARE_BITMAP(dirty[VNC_MAX_HEIGHT],
|
|
|
|
VNC_MAX_WIDTH / VNC_DIRTY_PIXELS_PER_BIT);
|
2011-02-04 09:05:55 +01:00
|
|
|
VncRectStat stats[VNC_STAT_ROWS][VNC_STAT_COLS];
|
2012-10-10 13:29:43 +02:00
|
|
|
pixman_image_t *fb;
|
|
|
|
pixman_format_code_t format;
|
2009-08-03 11:54:32 +02:00
|
|
|
};
|
2009-03-06 21:27:23 +01:00
|
|
|
|
2011-11-24 18:10:49 +01:00
|
|
|
typedef enum VncShareMode {
|
|
|
|
VNC_SHARE_MODE_CONNECTING = 1,
|
|
|
|
VNC_SHARE_MODE_SHARED,
|
|
|
|
VNC_SHARE_MODE_EXCLUSIVE,
|
|
|
|
VNC_SHARE_MODE_DISCONNECTED,
|
|
|
|
} VncShareMode;
|
|
|
|
|
|
|
|
typedef enum VncSharePolicy {
|
|
|
|
VNC_SHARE_POLICY_IGNORE = 1,
|
|
|
|
VNC_SHARE_POLICY_ALLOW_EXCLUSIVE,
|
|
|
|
VNC_SHARE_POLICY_FORCE_SHARED,
|
|
|
|
} VncSharePolicy;
|
|
|
|
|
2009-03-06 21:27:13 +01:00
|
|
|
struct VncDisplay
|
|
|
|
{
|
2010-02-05 12:04:05 +01:00
|
|
|
QTAILQ_HEAD(, VncState) clients;
|
2014-10-02 12:09:34 +02:00
|
|
|
int num_connecting;
|
|
|
|
int num_shared;
|
2011-11-24 18:10:49 +01:00
|
|
|
int num_exclusive;
|
2014-10-02 12:09:34 +02:00
|
|
|
int connections_limit;
|
2011-11-24 18:10:49 +01:00
|
|
|
VncSharePolicy share_policy;
|
2018-02-01 17:45:14 +01:00
|
|
|
QIONetListener *listener;
|
|
|
|
QIONetListener *wslistener;
|
2013-02-28 17:16:48 +01:00
|
|
|
DisplaySurface *ds;
|
2013-02-28 11:34:31 +01:00
|
|
|
DisplayChangeListener dcl;
|
2009-10-01 23:12:16 +02:00
|
|
|
kbd_layout_t *kbd_layout;
|
2010-03-10 17:12:02 +01:00
|
|
|
int lock_key_sync;
|
2017-01-09 17:14:02 +01:00
|
|
|
QEMUPutLEDEntry *led;
|
|
|
|
int ledstate;
|
2019-01-22 10:28:12 +01:00
|
|
|
QKbdState *kbd;
|
2010-07-07 20:58:02 +02:00
|
|
|
QemuMutex mutex;
|
2009-03-06 21:27:13 +01:00
|
|
|
|
2010-05-21 11:54:34 +02:00
|
|
|
QEMUCursor *cursor;
|
|
|
|
int cursor_msize;
|
|
|
|
uint8_t *cursor_mask;
|
|
|
|
|
2009-08-03 11:54:32 +02:00
|
|
|
struct VncSurface guest; /* guest visible surface (aka ds->surface) */
|
2012-10-10 13:29:43 +02:00
|
|
|
pixman_image_t *server; /* vnc server surface */
|
2009-08-03 11:54:32 +02:00
|
|
|
|
2014-07-29 12:14:08 +02:00
|
|
|
const char *id;
|
|
|
|
QTAILQ_ENTRY(VncDisplay) next;
|
2015-02-19 10:46:49 +01:00
|
|
|
bool is_unix;
|
2009-03-06 21:27:13 +01:00
|
|
|
char *password;
|
2010-10-07 11:50:45 +02:00
|
|
|
time_t expires;
|
2009-03-06 21:27:13 +01:00
|
|
|
int auth;
|
2015-03-17 14:42:55 +01:00
|
|
|
int subauth; /* Used by VeNCrypt */
|
2015-03-17 14:42:57 +01:00
|
|
|
int ws_auth; /* Used by websockets */
|
2016-09-29 17:45:36 +02:00
|
|
|
int ws_subauth; /* Used by websockets */
|
2010-07-07 20:57:51 +02:00
|
|
|
bool lossy;
|
2011-02-04 09:06:08 +01:00
|
|
|
bool non_adaptive;
|
ui: convert VNC server to use QCryptoTLSSession
Switch VNC server over to using the QCryptoTLSSession object
for the TLS session. This removes the direct use of gnutls
from the VNC server code. It also removes most knowledge
about TLS certificate handling from the VNC server code.
This has the nice effect that all the CONFIG_VNC_TLS
conditionals go away and the user gets an actual error
message when requesting TLS instead of it being silently
ignored.
With this change, the existing configuration options for
enabling TLS with -vnc are deprecated.
Old syntax for anon-DH credentials:
-vnc hostname:0,tls
New syntax:
-object tls-creds-anon,id=tls0,endpoint=server \
-vnc hostname:0,tls-creds=tls0
Old syntax for x509 credentials, no client certs:
-vnc hostname:0,tls,x509=/path/to/certs
New syntax:
-object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \
-vnc hostname:0,tls-creds=tls0
Old syntax for x509 credentials, requiring client certs:
-vnc hostname:0,tls,x509verify=/path/to/certs
New syntax:
-object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \
-vnc hostname:0,tls-creds=tls0
This aligns VNC with the way TLS credentials are to be
configured in the future for chardev, nbd and migration
backends. It also has the benefit that the same TLS
credentials can be shared across multiple VNC server
instances, if desired.
If someone uses the deprecated syntax, it will internally
result in the creation of a 'tls-creds' object with an ID
based on the VNC server ID. This allows backwards compat
with the CLI syntax, while still deleting all the original
TLS code from the VNC server.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-08-06 15:39:32 +02:00
|
|
|
QCryptoTLSCreds *tlscreds;
|
2016-02-18 19:40:24 +01:00
|
|
|
QAuthZ *tlsauthz;
|
|
|
|
char *tlsauthzid;
|
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 21:27:37 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
VncDisplaySASL sasl;
|
|
|
|
#endif
|
2019-08-19 01:06:48 +02:00
|
|
|
|
|
|
|
AudioState *audio_state;
|
2009-03-06 21:27:13 +01:00
|
|
|
};
|
|
|
|
|
2010-07-07 20:57:59 +02:00
|
|
|
typedef struct VncTight {
|
|
|
|
int type;
|
|
|
|
uint8_t quality;
|
|
|
|
uint8_t compression;
|
|
|
|
uint8_t pixel24;
|
|
|
|
Buffer tight;
|
|
|
|
Buffer tmp;
|
|
|
|
Buffer zlib;
|
|
|
|
Buffer gradient;
|
|
|
|
#ifdef CONFIG_VNC_JPEG
|
|
|
|
Buffer jpeg;
|
|
|
|
#endif
|
|
|
|
#ifdef CONFIG_VNC_PNG
|
|
|
|
Buffer png;
|
|
|
|
#endif
|
|
|
|
int levels[4];
|
|
|
|
z_stream stream[4];
|
|
|
|
} VncTight;
|
|
|
|
|
|
|
|
typedef struct VncHextile {
|
|
|
|
VncSendHextileTile *send_tile;
|
|
|
|
} VncHextile;
|
|
|
|
|
|
|
|
typedef struct VncZlib {
|
|
|
|
Buffer zlib;
|
|
|
|
Buffer tmp;
|
|
|
|
z_stream stream;
|
|
|
|
int level;
|
|
|
|
} VncZlib;
|
|
|
|
|
2011-02-04 09:06:01 +01:00
|
|
|
typedef struct VncZrle {
|
|
|
|
int type;
|
|
|
|
Buffer fb;
|
|
|
|
Buffer zrle;
|
|
|
|
Buffer tmp;
|
|
|
|
Buffer zlib;
|
|
|
|
z_stream stream;
|
|
|
|
VncPalette palette;
|
|
|
|
} VncZrle;
|
|
|
|
|
|
|
|
typedef struct VncZywrle {
|
|
|
|
int buf[VNC_ZRLE_TILE_WIDTH * VNC_ZRLE_TILE_HEIGHT];
|
|
|
|
} VncZywrle;
|
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
struct VncRect
|
|
|
|
{
|
|
|
|
int x;
|
|
|
|
int y;
|
|
|
|
int w;
|
|
|
|
int h;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct VncRectEntry
|
|
|
|
{
|
|
|
|
struct VncRect rect;
|
|
|
|
QLIST_ENTRY(VncRectEntry) next;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct VncJob
|
|
|
|
{
|
|
|
|
VncState *vs;
|
|
|
|
|
|
|
|
QLIST_HEAD(, VncRectEntry) rectangles;
|
|
|
|
QTAILQ_ENTRY(VncJob) next;
|
|
|
|
};
|
|
|
|
|
2017-12-18 20:12:21 +01:00
|
|
|
typedef enum {
|
|
|
|
VNC_STATE_UPDATE_NONE,
|
|
|
|
VNC_STATE_UPDATE_INCREMENTAL,
|
|
|
|
VNC_STATE_UPDATE_FORCE,
|
|
|
|
} VncStateUpdate;
|
|
|
|
|
2018-05-07 12:22:54 +02:00
|
|
|
#define VNC_MAGIC ((uint64_t)0x05b3f069b3d204bb)
|
|
|
|
|
2009-03-06 21:27:13 +01:00
|
|
|
struct VncState
|
|
|
|
{
|
2018-05-07 12:22:54 +02:00
|
|
|
uint64_t magic;
|
2015-02-27 17:20:57 +01:00
|
|
|
QIOChannelSocket *sioc; /* The underlying socket */
|
|
|
|
QIOChannel *ioc; /* The channel currently used for I/O */
|
|
|
|
guint ioc_tag;
|
|
|
|
gboolean disconnecting;
|
2009-03-20 16:59:14 +01:00
|
|
|
|
2011-03-03 21:37:55 +01:00
|
|
|
DECLARE_BITMAP(dirty[VNC_MAX_HEIGHT], VNC_DIRTY_BITS);
|
2011-02-04 09:05:56 +01:00
|
|
|
uint8_t **lossy_rect; /* Not an Array to avoid costly memcpy in
|
|
|
|
* vnc-jobs-async.c */
|
2009-03-20 16:59:14 +01:00
|
|
|
|
2009-03-06 21:27:13 +01:00
|
|
|
VncDisplay *vd;
|
2017-12-18 20:12:21 +01:00
|
|
|
VncStateUpdate update; /* Most recent pending request from client */
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
VncStateUpdate job_update; /* Currently processed by job thread */
|
2014-07-23 11:52:02 +02:00
|
|
|
int has_dirty;
|
2009-03-06 21:27:13 +01:00
|
|
|
uint32_t features;
|
|
|
|
int absolute;
|
|
|
|
int last_x;
|
|
|
|
int last_y;
|
2013-12-02 15:17:45 +01:00
|
|
|
uint32_t last_bmask;
|
ui: avoid sign extension using client width/height
Pixman returns a signed int for the image width/height, but the VNC
protocol only permits a unsigned int16. Effective framebuffer size
is determined by the guest, limited by the video RAM size, so the
dimensions are unlikely to exceed the range of an unsigned int16,
but this is not currently validated.
With the current use of 'int' for client width/height, the calculation
of offsets in vnc_update_throttle_offset() suffers from integer size
promotion and sign extension, causing coverity warnings
*** CID 1385147: Integer handling issues (SIGN_EXTENSION)
/ui/vnc.c: 979 in vnc_update_throttle_offset()
973 * than that the client would already suffering awful audio
974 * glitches, so dropping samples is no worse really).
975 */
976 static void vnc_update_throttle_offset(VncState *vs)
977 {
978 size_t offset =
>>> CID 1385147: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension:
"vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits,
unsigned) is promoted in "vs->client_width * vs->client_height *
vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then
sign-extended to type "unsigned long" (64 bits, unsigned). If
"vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel"
is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
979 vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel;
Change client_width / client_height to be a size_t to avoid sign
extension and integer promotion. Then validate that dimensions are in
range wrt the RFB protocol u16 limits.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20180118155254.17053-1-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-18 16:52:54 +01:00
|
|
|
size_t client_width; /* limited to u16 by RFB proto */
|
|
|
|
size_t client_height; /* limited to u16 by RFB proto */
|
2011-11-24 18:10:49 +01:00
|
|
|
VncShareMode share_mode;
|
2009-03-06 21:27:13 +01:00
|
|
|
|
|
|
|
uint32_t vnc_encoding;
|
|
|
|
|
|
|
|
int major;
|
|
|
|
int minor;
|
|
|
|
|
2011-06-23 14:31:41 +02:00
|
|
|
int auth;
|
2015-03-17 14:42:55 +01:00
|
|
|
int subauth; /* Used by VeNCrypt */
|
2009-03-06 21:27:13 +01:00
|
|
|
char challenge[VNC_AUTH_CHALLENGE_SIZE];
|
2015-03-02 20:01:05 +01:00
|
|
|
QCryptoTLSSession *tls; /* Borrowed pointer from channel, don't free */
|
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 21:27:28 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
VncStateSASL sasl;
|
|
|
|
#endif
|
2013-01-21 11:04:44 +01:00
|
|
|
bool encode_ws;
|
|
|
|
bool websocket;
|
2009-03-06 21:27:13 +01:00
|
|
|
|
qapi: add conditions to VNC type/commands/events on the schema
Add #if defined(CONFIG_VNC) in generated code, and adjust the
qmp/hmp code accordingly.
query-qmp-schema no longer reports the command/events etc as
available when disabled at compile.
Commands made conditional:
* query-vnc, query-vnc-servers, change-vnc-password
Before the patch, the commands for !CONFIG_VNC are stubs that fail
like this:
{"error": {"class": "GenericError",
"desc": "The feature 'vnc' is not enabled"}}
Afterwards, they fail like this:
{"error": {"class": "CommandNotFound",
"desc": "The command FOO has not been found"}}
I call that an improvement, because it lets clients distinguish
between command unavailable (class CommandNotFound) and command failed
(class GenericError).
Events made conditional:
* VNC_CONNECTED, VNC_INITIALIZED, VNC_DISCONNECTED
HMP change:
* info vnc
Will return "unknown command: 'info vnc'" when VNC is compiled
out (same as error for spice when --disable-spice)
Occurrences of VNC (case insensitive) in the schema that aren't
covered by this change:
* add_client
Command has other uses, including "socket bases character devices".
These are unconditional as far as I can tell.
* set_password, expire_password
In theory, these commands could be used for managing any service's
password. In practice, they're used for VNC and SPICE services.
They're documented for "remote display session" / "remote display
server".
The service is selected by argument @protocol. The code special-cases
protocol-specific argument checking, then calls a protocol-specific
function to do the work. If it fails, the command fails with "Could
not set password". It does when the service isn't compiled in (it's a
stub then).
We could make these commands conditional on the conjunction of all
services [currently: defined(CONFIG_VNC) || defined(CONFIG_SPICE)],
but I doubt it's worthwhile.
* change
Command has other uses, namely changing media.
This patch inlines a stub; no functional change.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20180703155648.11933-14-marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03 17:56:47 +02:00
|
|
|
#ifdef CONFIG_VNC
|
2014-06-18 08:43:49 +02:00
|
|
|
VncClientInfo *info;
|
qapi: add conditions to VNC type/commands/events on the schema
Add #if defined(CONFIG_VNC) in generated code, and adjust the
qmp/hmp code accordingly.
query-qmp-schema no longer reports the command/events etc as
available when disabled at compile.
Commands made conditional:
* query-vnc, query-vnc-servers, change-vnc-password
Before the patch, the commands for !CONFIG_VNC are stubs that fail
like this:
{"error": {"class": "GenericError",
"desc": "The feature 'vnc' is not enabled"}}
Afterwards, they fail like this:
{"error": {"class": "CommandNotFound",
"desc": "The command FOO has not been found"}}
I call that an improvement, because it lets clients distinguish
between command unavailable (class CommandNotFound) and command failed
(class GenericError).
Events made conditional:
* VNC_CONNECTED, VNC_INITIALIZED, VNC_DISCONNECTED
HMP change:
* info vnc
Will return "unknown command: 'info vnc'" when VNC is compiled
out (same as error for spice when --disable-spice)
Occurrences of VNC (case insensitive) in the schema that aren't
covered by this change:
* add_client
Command has other uses, including "socket bases character devices".
These are unconditional as far as I can tell.
* set_password, expire_password
In theory, these commands could be used for managing any service's
password. In practice, they're used for VNC and SPICE services.
They're documented for "remote display session" / "remote display
server".
The service is selected by argument @protocol. The code special-cases
protocol-specific argument checking, then calls a protocol-specific
function to do the work. If it fails, the command fails with "Could
not set password". It does when the service isn't compiled in (it's a
stub then).
We could make these commands conditional on the conjunction of all
services [currently: defined(CONFIG_VNC) || defined(CONFIG_SPICE)],
but I doubt it's worthwhile.
* change
Command has other uses, namely changing media.
This patch inlines a stub; no functional change.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20180703155648.11933-14-marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-07-03 17:56:47 +02:00
|
|
|
#endif
|
2010-01-14 17:50:56 +01:00
|
|
|
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
/* Job thread bottom half has put data for a forced update
|
|
|
|
* into the output buffer. This offset points to the end of
|
|
|
|
* the update data in the output buffer. This lets us determine
|
|
|
|
* when a force update is fully sent to the client, allowing
|
|
|
|
* us to process further forced updates. */
|
|
|
|
size_t force_update_offset;
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
/* We allow multiple incremental updates or audio capture
|
|
|
|
* samples to be queued in output buffer, provided the
|
|
|
|
* buffer size doesn't exceed this threshold. The value
|
|
|
|
* is calculating dynamically based on framebuffer size
|
|
|
|
* and audio sample settings in vnc_update_throttle_offset() */
|
|
|
|
size_t throttle_output_offset;
|
2009-03-06 21:27:13 +01:00
|
|
|
Buffer output;
|
|
|
|
Buffer input;
|
|
|
|
/* current output mode information */
|
|
|
|
VncWritePixels *write_pixels;
|
2012-10-10 13:29:43 +02:00
|
|
|
PixelFormat client_pf;
|
|
|
|
pixman_format_code_t client_format;
|
|
|
|
bool client_be;
|
2009-03-06 21:27:13 +01:00
|
|
|
|
|
|
|
CaptureVoiceOut *audio_cap;
|
|
|
|
struct audsettings as;
|
|
|
|
|
|
|
|
VncReadEvent *read_handler;
|
|
|
|
size_t read_handler_expect;
|
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
bool abort;
|
|
|
|
QemuMutex output_mutex;
|
2012-03-14 07:58:47 +01:00
|
|
|
QEMUBH *bh;
|
|
|
|
Buffer jobs_buffer;
|
2010-07-07 20:58:02 +02:00
|
|
|
|
|
|
|
/* Encoding specific, if you add something here, don't forget to
|
|
|
|
* update vnc_async_encoding_start()
|
|
|
|
*/
|
2019-08-31 17:39:22 +02:00
|
|
|
VncTight *tight;
|
2010-07-07 20:57:59 +02:00
|
|
|
VncZlib zlib;
|
|
|
|
VncHextile hextile;
|
2019-08-31 17:39:22 +02:00
|
|
|
VncZrle *zrle;
|
2011-02-04 09:06:01 +01:00
|
|
|
VncZywrle zywrle;
|
2009-03-06 21:27:13 +01:00
|
|
|
|
2010-03-10 16:38:29 +01:00
|
|
|
Notifier mouse_mode_notifier;
|
|
|
|
|
2010-02-05 12:04:05 +01:00
|
|
|
QTAILQ_ENTRY(VncState) next;
|
2009-03-06 21:27:13 +01:00
|
|
|
};
|
|
|
|
|
2009-02-02 16:58:25 +01:00
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
*
|
|
|
|
* 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 21:27:28 +01: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 */
|
2009-02-02 16:58:25 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
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 21:27:28 +01:00
|
|
|
VNC_AUTH_VENCRYPT_X509SASL = 263,
|
|
|
|
VNC_AUTH_VENCRYPT_TLSSASL = 264,
|
2009-02-02 16:58:25 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
*
|
|
|
|
* 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 */
|
2010-07-07 20:57:56 +02:00
|
|
|
#define VNC_ENCODING_TIGHT_PNG 0xFFFFFEFC /* -260 */
|
2013-04-25 07:29:10 +02:00
|
|
|
#define VNC_ENCODING_LED_STATE 0XFFFFFEFB /* -261 */
|
2009-02-02 16:58:25 +01:00
|
|
|
#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)
|
2010-07-07 20:57:56 +02:00
|
|
|
#define VNC_TIGHT_CCB_TYPE_PNG (0x0A << 4)
|
2009-02-02 16:58:25 +01:00
|
|
|
#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
|
2009-02-16 15:59:30 +01:00
|
|
|
#define VNC_FEATURE_COPYRECT 6
|
2010-05-21 11:54:34 +02:00
|
|
|
#define VNC_FEATURE_RICH_CURSOR 7
|
2010-07-07 20:57:56 +02:00
|
|
|
#define VNC_FEATURE_TIGHT_PNG 8
|
2011-02-04 09:06:01 +01:00
|
|
|
#define VNC_FEATURE_ZRLE 9
|
|
|
|
#define VNC_FEATURE_ZYWRLE 10
|
2013-04-25 07:29:10 +02:00
|
|
|
#define VNC_FEATURE_LED_STATE 11
|
2009-02-02 16:58:25 +01:00
|
|
|
|
|
|
|
#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)
|
2009-02-16 15:59:30 +01:00
|
|
|
#define VNC_FEATURE_COPYRECT_MASK (1 << VNC_FEATURE_COPYRECT)
|
2010-05-21 11:54:34 +02:00
|
|
|
#define VNC_FEATURE_RICH_CURSOR_MASK (1 << VNC_FEATURE_RICH_CURSOR)
|
2010-07-07 20:57:56 +02:00
|
|
|
#define VNC_FEATURE_TIGHT_PNG_MASK (1 << VNC_FEATURE_TIGHT_PNG)
|
2011-02-04 09:06:01 +01:00
|
|
|
#define VNC_FEATURE_ZRLE_MASK (1 << VNC_FEATURE_ZRLE)
|
|
|
|
#define VNC_FEATURE_ZYWRLE_MASK (1 << VNC_FEATURE_ZYWRLE)
|
2013-04-25 07:29:10 +02:00
|
|
|
#define VNC_FEATURE_LED_STATE_MASK (1 << VNC_FEATURE_LED_STATE)
|
2009-02-02 16:58:25 +01:00
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
|
2010-03-31 19:20:43 +02:00
|
|
|
/* Client -> Server message IDs */
|
|
|
|
#define VNC_MSG_CLIENT_SET_PIXEL_FORMAT 0
|
|
|
|
#define VNC_MSG_CLIENT_SET_ENCODINGS 2
|
|
|
|
#define VNC_MSG_CLIENT_FRAMEBUFFER_UPDATE_REQUEST 3
|
|
|
|
#define VNC_MSG_CLIENT_KEY_EVENT 4
|
|
|
|
#define VNC_MSG_CLIENT_POINTER_EVENT 5
|
|
|
|
#define VNC_MSG_CLIENT_CUT_TEXT 6
|
|
|
|
#define VNC_MSG_CLIENT_VMWARE_0 127
|
|
|
|
#define VNC_MSG_CLIENT_CALL_CONTROL 249
|
|
|
|
#define VNC_MSG_CLIENT_XVP 250
|
|
|
|
#define VNC_MSG_CLIENT_SET_DESKTOP_SIZE 251
|
|
|
|
#define VNC_MSG_CLIENT_TIGHT 252
|
|
|
|
#define VNC_MSG_CLIENT_GII 253
|
|
|
|
#define VNC_MSG_CLIENT_VMWARE_1 254
|
|
|
|
#define VNC_MSG_CLIENT_QEMU 255
|
|
|
|
|
|
|
|
/* Server -> Client message IDs */
|
|
|
|
#define VNC_MSG_SERVER_FRAMEBUFFER_UPDATE 0
|
|
|
|
#define VNC_MSG_SERVER_SET_COLOUR_MAP_ENTRIES 1
|
|
|
|
#define VNC_MSG_SERVER_BELL 2
|
|
|
|
#define VNC_MSG_SERVER_CUT_TEXT 3
|
|
|
|
#define VNC_MSG_SERVER_VMWARE_0 127
|
|
|
|
#define VNC_MSG_SERVER_CALL_CONTROL 249
|
|
|
|
#define VNC_MSG_SERVER_XVP 250
|
|
|
|
#define VNC_MSG_SERVER_TIGHT 252
|
|
|
|
#define VNC_MSG_SERVER_GII 253
|
|
|
|
#define VNC_MSG_SERVER_VMWARE_1 254
|
|
|
|
#define VNC_MSG_SERVER_QEMU 255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* QEMU client -> server message IDs */
|
|
|
|
#define VNC_MSG_CLIENT_QEMU_EXT_KEY_EVENT 0
|
|
|
|
#define VNC_MSG_CLIENT_QEMU_AUDIO 1
|
|
|
|
|
|
|
|
/* QEMU server -> client message IDs */
|
|
|
|
#define VNC_MSG_SERVER_QEMU_AUDIO 1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* QEMU client -> server audio message IDs */
|
|
|
|
#define VNC_MSG_CLIENT_QEMU_AUDIO_ENABLE 0
|
|
|
|
#define VNC_MSG_CLIENT_QEMU_AUDIO_DISABLE 1
|
|
|
|
#define VNC_MSG_CLIENT_QEMU_AUDIO_SET_FORMAT 2
|
|
|
|
|
|
|
|
/* QEMU server -> client audio message IDs */
|
|
|
|
#define VNC_MSG_SERVER_QEMU_AUDIO_END 0
|
|
|
|
#define VNC_MSG_SERVER_QEMU_AUDIO_BEGIN 1
|
|
|
|
#define VNC_MSG_SERVER_QEMU_AUDIO_DATA 2
|
|
|
|
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
*
|
|
|
|
* Internal APIs
|
|
|
|
*
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
/* Event loop functions */
|
2015-02-27 17:20:57 +01:00
|
|
|
gboolean vnc_client_io(QIOChannel *ioc,
|
|
|
|
GIOCondition condition,
|
|
|
|
void *opaque);
|
2009-03-06 21:27:23 +01:00
|
|
|
|
2017-12-18 20:12:28 +01:00
|
|
|
size_t vnc_client_read_buf(VncState *vs, uint8_t *data, size_t datalen);
|
|
|
|
size_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen);
|
2009-03-06 21:27:23 +01: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);
|
2013-01-21 11:04:44 +01:00
|
|
|
void vnc_disconnect_finish(VncState *vs);
|
2016-09-29 17:45:40 +02:00
|
|
|
void vnc_start_protocol(VncState *vs);
|
2009-03-06 21:27:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
/* Buffer I/O functions */
|
|
|
|
uint32_t read_u32(uint8_t *data, size_t offset);
|
|
|
|
|
|
|
|
/* Protocol stage functions */
|
|
|
|
void vnc_client_error(VncState *vs);
|
2019-12-05 18:46:19 +01:00
|
|
|
size_t vnc_client_io_error(VncState *vs, ssize_t ret, Error *err);
|
2009-03-06 21:27:23 +01: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 21:27:28 +01:00
|
|
|
|
|
|
|
/* Misc helpers */
|
|
|
|
|
2010-07-07 20:57:56 +02:00
|
|
|
static inline uint32_t vnc_has_feature(VncState *vs, int feature) {
|
|
|
|
return (vs->features & (1 << feature));
|
|
|
|
}
|
|
|
|
|
2010-05-03 14:31:34 +02:00
|
|
|
/* Framebuffer */
|
|
|
|
void vnc_framebuffer_update(VncState *vs, int x, int y, int w, int h,
|
|
|
|
int32_t encoding);
|
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
/* server fb is in PIXMAN_x8r8g8b8 */
|
|
|
|
#define VNC_SERVER_FB_FORMAT PIXMAN_FORMAT(32, PIXMAN_TYPE_ARGB, 0, 8, 8, 8)
|
|
|
|
#define VNC_SERVER_FB_BITS (PIXMAN_FORMAT_BPP(VNC_SERVER_FB_FORMAT))
|
|
|
|
#define VNC_SERVER_FB_BYTES ((VNC_SERVER_FB_BITS+7)/8)
|
|
|
|
|
|
|
|
void *vnc_server_fb_ptr(VncDisplay *vd, int x, int y);
|
|
|
|
int vnc_server_fb_stride(VncDisplay *vd);
|
|
|
|
|
2010-05-03 14:31:34 +02:00
|
|
|
void vnc_convert_pixel(VncState *vs, uint8_t *buf, uint32_t v);
|
2011-02-04 09:05:55 +01:00
|
|
|
double vnc_update_freq(VncState *vs, int x, int y, int w, int h);
|
2011-02-04 09:05:56 +01:00
|
|
|
void vnc_sent_lossy_rect(VncState *vs, int x, int y, int w, int h);
|
2010-05-03 14:31:34 +02:00
|
|
|
|
|
|
|
/* Encodings */
|
2010-07-07 20:58:02 +02:00
|
|
|
int vnc_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
|
|
|
|
|
2010-05-19 09:24:09 +02:00
|
|
|
int vnc_raw_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
|
2010-05-03 14:31:34 +02:00
|
|
|
|
2010-05-19 09:24:09 +02:00
|
|
|
int vnc_hextile_send_framebuffer_update(VncState *vs, int x,
|
2010-05-03 14:31:34 +02:00
|
|
|
int y, int w, int h);
|
|
|
|
void vnc_hextile_set_pixel_conversion(VncState *vs, int generic);
|
|
|
|
|
2010-05-19 09:24:10 +02:00
|
|
|
void *vnc_zlib_zalloc(void *x, unsigned items, unsigned size);
|
|
|
|
void vnc_zlib_zfree(void *x, void *addr);
|
2010-05-19 09:24:09 +02:00
|
|
|
int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
|
2010-05-19 09:24:08 +02:00
|
|
|
void vnc_zlib_clear(VncState *vs);
|
2010-05-03 14:31:34 +02:00
|
|
|
|
2010-05-19 09:24:10 +02:00
|
|
|
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
|
2010-07-07 20:57:56 +02:00
|
|
|
int vnc_tight_png_send_framebuffer_update(VncState *vs, int x, int y,
|
|
|
|
int w, int h);
|
2010-05-19 09:24:10 +02:00
|
|
|
void vnc_tight_clear(VncState *vs);
|
|
|
|
|
2011-02-04 09:06:01 +01:00
|
|
|
int vnc_zrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
|
|
|
|
int vnc_zywrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
|
|
|
|
void vnc_zrle_clear(VncState *vs);
|
|
|
|
|
2016-06-29 13:47:03 +02:00
|
|
|
#endif /* QEMU_VNC_H */
|