Monitor commands related to display server passwords

* Monitor commands related to display server passwords
@ 2022-11-30  8:02 Markus Armbruster
  2022-11-30  9:03 ` Daniel P. Berrangé
  0 siblings, 1 reply; 6+ messages in thread
From: Markus Armbruster @ 2022-11-30  8:02 UTC (permalink / raw)
  To: qemu-devel; +Cc: Gerd Hoffmann, Daniel P. Berrangé

We have a couple of password-related commands, and I'm not sure about
which ones should be used.  In order of appearance:

* HMP change vnc

  Change a VNC server password.  Unlike set_password below, there's no
  way to select a display other than the first.

  Note: if change's second argument isn't "vnc", w're changing removable
  media.  If you call your block device "vnc", you cannot change its
  media.  Hilarious.

  Password prompting (with hidden user input) since commit 7084851534
  "VNC password authentication, by Daniel P. Berrange." (v0.9.1,
  2007-08-25).

  Password argument since commit 2569da0cb6 "Accept password as an
  argument to 'change vnc password' monitor command (Chris Webb)"
  (v0.10.0, 2008-12-10).

  Nowadays, this wraps around QMP change-vnc-password, discussed below.

* HMP and QMP set_password, expire_password

  Change a VNC or Spice server password.  For Spice, can optionally fail
  when connections exist, or disconnect them.

  HMP commands wrap around the respective QMP command, as they should.

  HMP set_password does not support password prompting like "change vnc"
  does.

  Commands are present even when both CONFIG_VNC and CONFIG_SPICE are
  off.  Attempts to use them are rejected manually.  Defeats
  introspection.

  Since commit 7572150c18 "vnc/spice: add set_passwd monitor command."
  (v0.14.0, 2010-12-09)

  Support for VNC displays other than the first since commit 675fd3c96b
  "qapi/monitor: allow VNC display id in set/expire_password" (v7.0.0,
  2022-03-02).

* QMP change-vnc-password

  Can only target the first VNC display, unlike set_password.

  Command present only with CONFIG_VNC.

  Since commit 270b243f91 "qapi: Introduce change-vnc-password" (v1.1,
  2012-01-18).

Do we really need / want both set_password and change-vnc-password in
QMP?

On the one hand, set_password feels outdated from a QAPI point of view:
it violates the naming rules, and it defeats introspection.  On the
other hand, it's more powerful.

Do we really need / want both set_password and "change vnc" in HMP?
set_password is more powerful, but only "change vnc" supports password
prompting.

Getting rid of "change vnc" would fix the "cannot change media for block
device named 'vnc'" wart.

Related: QCryptoSecret objects.

commit ac1d88784907c9603b3849b2c3043259f75ed2a5
Author: Daniel P. Berrangé <berrange@redhat.com>
Date:   Wed Oct 14 09:58:38 2015 +0100

    crypto: add QCryptoSecret object class for password/key handling

    Introduce a new QCryptoSecret object class which will be used
    for providing passwords and keys to other objects which need
    sensitive credentials.

    The new object can provide secret values directly as properties,
    or indirectly via a file. The latter includes support for file
    descriptor passing syntax on UNIX platforms. Ordinarily passing
    secret values directly as properties is insecure, since they
    are visible in process listings, or in log files showing the
    CLI args / QMP commands. It is possible to use AES-256-CBC to
    encrypt the secret values though, in which case all that is
    visible is the ciphertext.  For ad hoc developer testing though,
    it is fine to provide the secrets directly without encryption
    so this is not explicitly forbidden.

    The anticipated scenario is that libvirtd will create a random
    master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key)
    and will use that key to encrypt all passwords it provides to
    QEMU via '-object secret,....'.  This avoids the need for libvirt
    (or other mgmt apps) to worry about file descriptor passing.

    It also makes life easier for people who are scripting the
    management of QEMU, for whom FD passing is significantly more
    complex.

    Providing data inline (insecure, only for ad hoc dev testing)

      $QEMU -object secret,id=sec0,data=letmein

    Providing data indirectly in raw format

      printf "letmein" > mypasswd.txt
      $QEMU -object secret,id=sec0,file=mypasswd.txt

    Providing data indirectly in base64 format

      $QEMU -object secret,id=sec0,file=mykey.b64,format=base64

    Providing data with encryption

      $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \
            -object secret,id=sec0,data=[base64 ciphertext],\
                       keyid=master0,iv=[base64 IV],format=base64

    Note that 'format' here refers to the format of the ciphertext
    data. The decrypted data must always be in raw byte format.

    More examples are shown in the updated docs.

    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

Currently used by various block backends and the tls-creds-x509 object.

Would it make sense with display servers, too?

^ permalink raw reply	[flat|nested] 6+ messages in thread