Merge remote-tracking branch 'remotes/berrange/tags/misc-next-pull-request' into staging

Merge misc fixes

A collection of patches I have fixing crypto code and other pieces
without an assigned maintainer

 * Fixes crypto function signatures to be compatible with
   both old and new versions of nettle
 * Fixes deprecation warnings on new nettle
 * Fixes GPL license header typos
 * Documents security implications of monitor usage
 * Optimize linking of capstone to avoid it in tools

# gpg: Signature made Fri 19 Jul 2019 14:24:37 BST
# gpg:                using RSA key DAF3A6FDB26B62912D0E8E3FBE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full]
# gpg:                 aka "Daniel P. Berrange <berrange@redhat.com>" [full]
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF

* remotes/berrange/tags/misc-next-pull-request:
  crypto: Fix LGPL information in the file headers
  doc: document that the monitor console is a privileged control interface
  configure: only link capstone to emulation targets
  crypto: fix function signatures for nettle 2.7 vs 3
  crypto: switch to modern nettle AES APIs

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

1 files changed, 36 insertions, 0 deletions

diff --git a/docs/security.texi b/docs/security.texi
index 927764f1e6..0d6b30edfc 100644
--- a/docs/security.texi
+++ b/docs/security.texi
@@ -129,3 +129,39 @@ those resources that were granted to it.
 system calls that are not needed by QEMU, thereby reducing the host kernel
 attack surface.
 @end itemize
+
+@section Sensitive configurations
+
+There are aspects of QEMU that can have security implications which users &
+management applications must be aware of.
+
+@subsection Monitor console (QMP and HMP)
+
+The monitor console (whether used with QMP or HMP) provides an interface
+to dynamically control many aspects of QEMU's runtime operation. Many of the
+commands exposed will instruct QEMU to access content on the host file system
+and/or trigger spawning of external processes.
+
+For example, the @code{migrate} command allows for the spawning of arbitrary
+processes for the purpose of tunnelling the migration data stream. The
+@code{blockdev-add} command instructs QEMU to open arbitrary files, exposing
+their content to the guest as a virtual disk.
+
+Unless QEMU is otherwise confined using technologies such as SELinux, AppArmor,
+or Linux namespaces, the monitor console should be considered to have privileges
+equivalent to those of the user account QEMU is running under.
+
+It is further important to consider the security of the character device backend
+over which the monitor console is exposed. It needs to have protection against
+malicious third parties which might try to make unauthorized connections, or
+perform man-in-the-middle attacks. Many of the character device backends do not
+satisfy this requirement and so must not be used for the monitor console.
+
+The general recommendation is that the monitor console should be exposed over
+a UNIX domain socket backend to the local host only. Use of the TCP based
+character device backend is inappropriate unless configured to use both TLS
+encryption and authorization control policy on client connections.
+
+In summary, the monitor console is considered a privileged control interface to
+QEMU and as such should only be made accessible to a trusted management
+application or user.