aboutsummaryrefslogtreecommitdiff
path: root/qemu-options.hx
diff options
context:
space:
mode:
authorDaniel P. Berrange <berrange@redhat.com>2019-03-08 15:21:50 +0000
committerPaolo Bonzini <pbonzini@redhat.com>2019-03-11 16:55:52 +0100
commitfd4a5fd4639bb1bfd04144fca85856d825e00ab4 (patch)
treea1fa2d9bd117b40e406a8bf1f8c476be5838b287 /qemu-options.hx
parent611dbe46093d901cf01c1b252dd39441b95d1c35 (diff)
chardev: add support for authorization for TLS clients
Currently any client which can complete the TLS handshake is able to use a chardev server. The server admin can turn on the 'verify-peer' option for the x509 creds to require the client to provide a x509 certificate. This means the client will have to acquire a certificate from the CA before they are permitted to use the chardev server. This is still a fairly low bar. This adds a 'tls-authz=OBJECT-ID' option to the socket chardev backend which takes the ID of a previously added 'QAuthZ' object instance. This will be used to validate the client's x509 distinguished name. Clients failing the check will not be permitted to use the chardev server. For example to setup authorization that only allows connection from a client whose x509 certificate distinguished name contains 'CN=fred', you would use: $QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\ endpoint=server,verify-peer=yes \ -object authz-simple,id=authz0,identity=CN=laptop.example.com,,\ O=Example Org,,L=London,,ST=London,,C=GB \ -chardev socket,host=127.0.0.1,port=9000,server,\ tls-creds=tls0,tls-authz=authz0 \ ...other qemu args... Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Diffstat (limited to 'qemu-options.hx')
-rw-r--r--qemu-options.hx10
1 files changed, 8 insertions, 2 deletions
diff --git a/qemu-options.hx b/qemu-options.hx
index c74f99b265..7118d90352 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2428,7 +2428,7 @@ DEF("chardev", HAS_ARG, QEMU_OPTION_chardev,
"-chardev null,id=id[,mux=on|off][,logfile=PATH][,logappend=on|off]\n"
"-chardev socket,id=id[,host=host],port=port[,to=to][,ipv4][,ipv6][,nodelay][,reconnect=seconds]\n"
" [,server][,nowait][,telnet][,websocket][,reconnect=seconds][,mux=on|off]\n"
- " [,logfile=PATH][,logappend=on|off][,tls-creds=ID] (tcp)\n"
+ " [,logfile=PATH][,logappend=on|off][,tls-creds=ID][,tls-authz=ID] (tcp)\n"
"-chardev socket,id=id,path=path[,server][,nowait][,telnet][,websocket][,reconnect=seconds]\n"
" [,mux=on|off][,logfile=PATH][,logappend=on|off] (unix)\n"
"-chardev udp,id=id[,host=host],port=port[,localaddr=localaddr]\n"
@@ -2557,7 +2557,7 @@ The available backends are:
A void device. This device will not emit any data, and will drop any data it
receives. The null backend does not take any options.
-@item -chardev socket,id=@var{id}[,@var{TCP options} or @var{unix options}][,server][,nowait][,telnet][,websocket][,reconnect=@var{seconds}][,tls-creds=@var{id}]
+@item -chardev socket,id=@var{id}[,@var{TCP options} or @var{unix options}][,server][,nowait][,telnet][,websocket][,reconnect=@var{seconds}][,tls-creds=@var{id}][,tls-authz=@var{id}]
Create a two-way stream socket, which can be either a TCP or a unix socket. A
unix socket will be created if @option{path} is specified. Behaviour is
@@ -2583,6 +2583,12 @@ and specifies the id of the TLS credentials to use for the handshake. The
credentials must be previously created with the @option{-object tls-creds}
argument.
+@option{tls-auth} provides the ID of the QAuthZ authorization object against
+which the client's x509 distinguished name will be validated. This object is
+only resolved at time of use, so can be deleted and recreated on the fly
+while the chardev server is active. If missing, it will default to denying
+access.
+
TCP and unix socket options are given below:
@table @option