1. 17 3月, 2016 3 次提交
  2. 19 12月, 2015 1 次提交
    • D
      crypto: add QCryptoSecret object class for password/key handling · ac1d8878
      Daniel P. Berrange 提交于
      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: NEric Blake <eblake@redhat.com>
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      ac1d8878
  3. 15 9月, 2015 5 次提交
    • D
      crypto: introduce new module for handling TLS sessions · d321e1e5
      Daniel P. Berrange 提交于
      Introduce a QCryptoTLSSession object that will encapsulate
      all the code for setting up and using a client/sever TLS
      session. This isolates the code which depends on the gnutls
      library, avoiding #ifdefs in the rest of the codebase, as
      well as facilitating any possible future port to other TLS
      libraries, if desired. It makes use of the previously
      defined QCryptoTLSCreds object to access credentials to
      use with the session. It also includes further unit tests
      to validate the correctness of the TLS session handshake
      and certificate validation. This is functionally equivalent
      to the current TLS session handling code embedded in the
      VNC server, and will obsolete it.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      d321e1e5
    • D
      crypto: introduce new module for TLS x509 credentials · 85bcbc78
      Daniel P. Berrange 提交于
      Introduce a QCryptoTLSCredsX509 class which is used to
      manage x509 certificate TLS credentials. This will be
      the preferred credential type offering strong security
      characteristics
      
      Example CLI configuration:
      
       $QEMU -object tls-creds-x509,id=tls0,endpoint=server,\
                     dir=/path/to/creds/dir,verify-peer=yes
      
      The 'id' value in the -object args will be used to associate the
      credentials with the network services. For example, when the VNC
      server is later converted it would use
      
       $QEMU -object tls-creds-x509,id=tls0,.... \
             -vnc 127.0.0.1:1,tls-creds=tls0
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      85bcbc78
    • D
      crypto: introduce new module for TLS anonymous credentials · e00adf6c
      Daniel P. Berrange 提交于
      Introduce a QCryptoTLSCredsAnon class which is used to
      manage anonymous TLS credentials. Use of this class is
      generally discouraged since it does not offer strong
      security, but it is required for backwards compatibility
      with the current VNC server implementation.
      
      Simple example CLI configuration:
      
       $QEMU -object tls-creds-anon,id=tls0,endpoint=server
      
      Example using pre-created diffie-hellman parameters
      
       $QEMU -object tls-creds-anon,id=tls0,endpoint=server,\
                     dir=/path/to/creds/dir
      
      The 'id' value in the -object args will be used to associate the
      credentials with the network services. For example, when the VNC
      server is later converted it would use
      
       $QEMU -object tls-creds-anon,id=tls0,.... \
             -vnc 127.0.0.1:1,tls-creds=tls0
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      e00adf6c
    • D
      crypto: introduce new base module for TLS credentials · a090187d
      Daniel P. Berrange 提交于
      Introduce a QCryptoTLSCreds class to act as the base class for
      storing TLS credentials. This will be later subclassed to provide
      handling of anonymous and x509 credential types. The subclasses
      will be user creatable objects, so instances can be created &
      deleted via 'object-add' and 'object-del' QMP commands respectively,
      or via the -object command line arg.
      
      If the credentials cannot be initialized an error will be reported
      as a QMP reply, or on stderr respectively.
      
      The idea is to make it possible to represent and manage TLS
      credentials independently of the network service that is using
      them. This will enable multiple services to use the same set of
      credentials and minimize code duplication. A later patch will
      convert the current VNC server TLS code over to use this object.
      
      The representation of credentials will be functionally equivalent
      to that currently implemented in the VNC server with one exception.
      The new code has the ability to (optionally) load a pre-generated
      set of diffie-hellman parameters, if the file dh-params.pem exists,
      whereas the current VNC server will always generate them on startup.
      This is beneficial for admins who wish to avoid the (small) time
      sink of generating DH parameters at startup and/or avoid depleting
      entropy.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a090187d
    • D
      crypto: move crypto objects out of libqemuutil.la · fb37726d
      Daniel P. Berrange 提交于
      Future patches will be adding more crypto related APIs which
      rely on QOM infrastructure. This creates a problem, because
      QOM relies on library constructors to register objects. When
      you have a file in a static .a library though which is only
      referenced by a constructor the linker is dumb and will drop
      that file when linking to the final executable :-( The only
      workaround for this is to link the .a library to the executable
      using the -Wl,--whole-archive flag, but this creates its own
      set of problems because QEMU is relying on lazy linking for
      libqemuutil.a. Using --whole-archive majorly increases the
      size of final executables as they now contain a bunch of
      object code they don't actually use.
      
      The least bad option is to thus not include the crypto objects
      in libqemuutil.la, and instead define a crypto-obj-y variable
      that is referenced directly by all the executables that need
      this code (tools + softmmu, but not qemu-ga). We avoid pulling
      entire of crypto-obj-y into the userspace emulators as that
      would force them to link to gnutls too, which is not required.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      fb37726d
  4. 08 7月, 2015 1 次提交
  5. 07 7月, 2015 3 次提交