qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH 00/15] Implement TLS support to QEMU NBD server & cl


From: Daniel P. Berrange
Subject: [Qemu-devel] [PATCH 00/15] Implement TLS support to QEMU NBD server & client
Date: Fri, 27 Nov 2015 12:20:38 +0000

This series of patches implements support for TLS in the QEMU NBD
server and client code.

It is implementing the NBD_OPT_STARTTLS option that was previously
discussed here:

  https://www.redhat.com/archives/libvir-list/2014-October/msg00506.html

And is also described in the NBD spec here:

  https://github.com/yoe/nbd/blob/master/doc/proto.md

Based on my impl I think the NBD_OPT_STARTTLS specification is
fine. In my impl, when TLS is requested in the server, I chose
to *refuse* all NBD options until NBD_OPT_STARTTLS has completed
successfully. There is an annoying thing about the fixed new style
protocol in that it made an exception for NBD_OPT_EXPORT_NAME,
so that it is still not possible to report errors for that option.

[qupte]
 - The server will reply to any option apart from `NBD_OPT_EXPORT_NAME`
    with reply packets in the following format:

  S: 64 bits, `0x3e889045565a9` (magic number for replies)  
  S: 32 bits, the option as sent by the client to which this is a reply  
  S: 32 bits, reply type (e.g., `NBD_REP_ACK` for successful completion,
     or `NBD_REP_ERR_UNSUP` to mark use of an option not known by this
     server  
  S: 32 bits, length of the reply. This may be zero for some replies, in
     which case the next field is not sent  
  S: any data as required by the reply (e.g., an export name in the case
     of `NBD_REP_SERVER`)
[/quote]

I wish those words "apart from NBD_OPT_EXPORT_NAME" were not there
for fixed new style protocol - maybe it needs a very-fixed new
style protocol...

As is, if the client connects to a TLS enabled NBD server and then
immediately sends NBD_OPT_EXPORT_NAME, it is not possible for us
to send back NBD_REP_ERR_TLS_REQD as the spec requires that the
server close the connection :-(  For this reason I have made the
qemu NBD client always send NBD_OPT_LIST as the first thing it
does, so that we can see the NBD_REP_ERR_TLS_REQD response.


I chose to *NOT* implement the NBD_OPT_PEEK_EXPORT option as it is
inherently insecure to have a client to ask the server which
exports need TLS, while the protocol is still running in plain text
mode, as it allows a trivial MITM downgrade attack. I can see value
in the NBD_OPT_PEEK_EXPORT option for probing other features, but
only after TLS has been negotiated. As such I believe NBD_F_EXP_TLS_OK
and NBD_F_EXP_TLS_REQ should be deleted from the spec as it is not
possible to use them in a secure manner.

This series of patches has my v3 I/O channels patch series as a
pre-requisite:

  https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04208.html

Usage of TLS is described in the commit messages for each patch,
but for sake of people who don't want to explore the series, here's
the summary

Starting QEMU system emulator with a disk backed by an TLS encrypted
NBD export

  $ qemu-system-x86_64 \
     -object 
tls-creds-x509,id=tls0,endpoint=client,dir=/home/berrange/security/qemutls
     -drive driver=nbd,host=localhost,port=9000,tls-creds=tls0

Starting a standalone NBD server providing a TLS encrypted NBD export

  $ qemu-nbd \
     --object 
tls-creds-x509,id=tls0,endpoint=server,dir=/home/berrange/security/qemutls
     --tls-creds tls0 \
     --exportname default

NB, exportname is mandatory, since TLS requires the fixed-new style
NBD protocol negotiation.

Starting a QEMU system emulator built-in NBD server

  $ qemu-system-x86_64 \
     -qmp unix:/tmp/qmp,server \
     -hda /home/berrange/Fedora-Server-netinst-x86_64-23.iso \
     -object 
tls-creds-x509,id=tls0,dir=/home/berrange/security/qemutls,endpoint=server

  $ qmp-shell /tmp/qmp
  (qmp) nbd-server-start addr={"host":"localhost","port":"9000"} tls-creds=tls0
  (qmp) nbd-server-add device=ide0-hd0

The first 6 patches are the conversion to the I/O channels
framework.

The next 5 patches are general tweaks to QEMU's impl of the
NBD protocol for better compliance and/or future proofing.

The next patch provides the NBD protocol TLS implementation.

The final 3 patches allow TLS to be enabled in the QEMU NBD
client and servers.


Daniel P. Berrange (15):
  qom: add user_creatable_add & user_creatable_del methods
  qemu-nbd: add support for --object command line arg
  nbd: convert block client to use I/O channels for connection setup
  nbd: convert qemu-nbd server to use I/O channels for connection setup
  nbd: convert blockdev NBD server to use I/O channels for connection
    setup
  nbd: convert to using I/O channels for actual socket I/O
  nbd: invert client logic for negotiating protocol version
  nbd: make server compliant with fixed newstyle spec
  nbd: make client request fixed new style if advertized
  nbd: allow setting of an export name for qemu-nbd server
  nbd: pick first exported volume if no export name is requested
  nbd: implement TLS support in the protocol negotiation
  nbd: enable use of TLS with NBD block driver
  nbd: enable use of TLS with qemu-nbd server
  nbd: enable use of TLS with nbd-server-start command

 Makefile                        |   6 +-
 block/nbd-client.c              |  74 ++--
 block/nbd-client.h              |  10 +-
 block/nbd.c                     | 105 ++++-
 blockdev-nbd.c                  | 132 +++++-
 hmp.c                           |  13 +-
 include/block/nbd.h             |  26 +-
 include/monitor/monitor.h       |   3 -
 include/qom/object_interfaces.h |  31 ++
 nbd.c                           | 890 ++++++++++++++++++++++++++++++++--------
 qapi/block.json                 |   4 +-
 qemu-nbd.c                      | 242 +++++++++--
 qemu-nbd.texi                   |  14 +
 qmp-commands.hx                 |   2 +-
 qmp.c                           |  75 +---
 qom/object_interfaces.c         |  76 ++++
 tests/Makefile                  |   2 +-
 vl.c                            |   8 +-
 18 files changed, 1333 insertions(+), 380 deletions(-)

-- 
2.5.0




reply via email to

[Prev in Thread] Current Thread [Next in Thread]