Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Feb 28, 2017 at 02:51:39PM -0800, ashish mittal wrote:
> On Mon, Feb 27, 2017 at 1:22 AM, Daniel P. Berrange <berrange@redhat.com> wrote:

> >> +        ret = -EINVAL;
> >> +        goto out;
> >> +    }
> >> +
> >> +    secretid = qemu_opt_get(opts, VXHS_OPT_SECRETID);
> >> +    if (!secretid) {
> >> +        error_setg(&local_err, "please specify the ID of the secret to be "
> >> +                   "used for authenticating to target");
> >> +        qdict_del(backing_options, str);
> >> +        ret = -EINVAL;
> >> +        goto out;
> >> +    }
> >> +
> >> +    /* check if we got password via the --object argument */
> >> +    password = qcrypto_secret_lookup_as_utf8(secretid, &local_err);
> >> +    if (local_err != NULL) {
> >> +        trace_vxhs_get_creds(user, secretid, password);
> >> +        qdict_del(backing_options, str);
> >> +        ret = -EINVAL;
> >> +        goto out;
> >> +    }
> >> +    trace_vxhs_get_creds(user, secretid, password);
> >> +
> >>      s->vdisk_hostinfo.host = g_strdup(server_host_opt);
> >>
> >>      s->vdisk_hostinfo.port = g_ascii_strtoll(qemu_opt_get(tcp_opts,
> 
> The next thing we need consensus on, is to decide exactly what
> additional information to pass.
> 
> (1) Current security implementation in VxHS uses the SSL key and
> certificate files. Do you think we can achieve all the intended
> security goals if we pass these two files paths (and names?) from the
> command line?

Yes, that's how other parts of QEMU deal with SSL

NB, QEMU needs to pass 3 paths to libqnoio - the client cert, the
client key, and the certificate authority certlist 

> (2) If we are OK to continue with the present security scheme (using
> key and cert), then the only additional change needed might be to
> accept these files on the command line.

Yep, I think that's the minimum required change to make this mergable.

> (3) If we decide to rely on file permissions and SELinux policy to
> protect these key/cert files, then we don't need to pass the file
> names as a secret, instead, passing them as regular qemu_opt_get()
> options might be enough.

That's correct - you can assume file permissions protect the cert
files. I would expect the syntax to work as follows

  $QEMU  -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu/vxhs,endpoint=client \
         -drive  driver=vxhs,...other..opts...,tls-creds=tls0

When you see the 'tls-creds' flag, you can lookup the corresponding
QCryptoTLSCredsX509 object and extract the 'dir' property from it.

The include/crypto/tlscredsx509.h file has constants defined for the
standard filenames - eg you would concatenate the directory with
the constants QCRYPTO_TLS_CREDS_X509_CLIENT_KEY.

This gives the filenames you can then pass to libqnio

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|