All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-block@nongnu.org, Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	Max Reitz <mreitz@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 1/2] qemu-nbd: add support for authorization of TLS clients
Date: Wed, 27 Feb 2019 15:58:28 +0000	[thread overview]
Message-ID: <20190227155828.GO31688@redhat.com> (raw)
In-Reply-To: <20190227153331.GL31688@redhat.com>

On Wed, Feb 27, 2019 at 03:33:31PM +0000, Daniel P. Berrangé wrote:
> On Wed, Feb 27, 2019 at 08:25:20AM -0600, Eric Blake wrote:
> > On 2/27/19 5:51 AM, Daniel P. Berrangé wrote:
> > > From: "Daniel P. Berrange" <berrange@redhat.com>
> > > 
> > > Currently any client which can complete the TLS handshake is able to use
> > > the NBD server. The server admin can turn on the 'verify-peer' option
> > > for the x509 creds to require the client to provide a x509 certificate.
> > > This means the client will have to acquire a certificate from the CA
> > > before they are permitted to use the NBD server. This is still a fairly
> > > low bar to cross.
> > > 
> > > This adds a '--tls-authz OBJECT-ID' option to the qemu-nbd command which
> > > takes the ID of a previously added 'QAuthZ' object instance. This will
> > > be used to validate the client's x509 distinguished name. Clients
> > > failing the authorization check will not be permitted to use the NBD
> > > server.
> > > 
> > > For example to setup authorization that only allows connection from a client
> > > whose x509 certificate distinguished name is
> > > 
> > >    CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
> > > 
> > > escape the commas in the name and use:
> > > 
> > >   qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
> > >                     endpoint=server,verify-peer=yes \
> > >            --object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
> > >                      O=Example Org,,L=London,,ST=London,,C=GB' \
> > >            --tls-creds tls0 \
> > >            --tls-authz authz0 \
> > > 	   ....other qemu-nbd args...
> > > 
> > > NB: a real shell command line would not have leading whitespace after
> > > the line continuation, it is just included here for clarity.


> > >  echo "== check TLS works =="
> > > -obj=tls-creds-x509,dir=${tls_dir}/client1,endpoint=client,id=tls0
> > > -$QEMU_IMG info --image-opts --object $obj \
> > > +obj1=tls-creds-x509,dir=${tls_dir}/client1,endpoint=client,id=tls0
> > > +obj2=tls-creds-x509,dir=${tls_dir}/client3,endpoint=client,id=tls0
> > > +$QEMU_IMG info --image-opts --object $obj1 \
> > >      driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
> > >      2>&1 | sed "s/$nbd_tcp_port/PORT/g"
> > > -$QEMU_NBD_PROG -L -b $nbd_tcp_addr -p $nbd_tcp_port --object $obj \
> > > +$QEMU_IMG info --image-opts --object $obj2 \
> > > +    driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
> > > +    2>&1 | sed "s/$nbd_tcp_port/PORT/g"
> > > +$QEMU_NBD_PROG -L -b $nbd_tcp_addr -p $nbd_tcp_port --object $obj1 \
> > >      --tls-creds=tls0
> > 
> > It looks like you have both a positive and negative test that a qemu-img
> > client can only connect with the right auth, but only a positive test
> > for a qemu-nbd --list client.  Should we also duplicate the
> > QEMU_NBD_PROG line to use $obj2 for a negative test?
> 
> I can look at that

On reflection I don't think that's needed. This is a server side feature we
are validating. As such it is sufficient to validate with any client app
supporting TLS. IOW, qemu-img is sufficient to prove the server side feature
is working correctly.

> 
> > 
> > >  
> > >  echo
> > > @@ -117,6 +122,26 @@ $QEMU_IO -c 'r -P 0x11 1m 1m' -c 'w -P 0x22 1m 1m' --image-opts \
> > >  
> > >  $QEMU_IO -f $IMGFMT -r -U -c 'r -P 0x22 1m 1m' "$TEST_IMG" | _filter_qemu_io
> > >  
> > > +echo
> > > +echo "== check TLS with authorization =="
> > > +
> > > +nbd_server_stop
> > > +
> > > +nbd_server_start_tcp_socket \
> > > +    --object tls-creds-x509,dir=${tls_dir}/server1,endpoint=server,id=tls0,verify-peer=yes \
> > > +    --object "authz-simple,identity=CN=localhost,,O=Cthulu Dark Lord Enterprises client1,,L=R'lyeh,,C=South Pacific,id=authz0" \
> > > +    --tls-authz authz0 \
> > > +    --tls-creds tls0 \
> > > +    -f $IMGFMT "$TEST_IMG" 2>> "$TEST_DIR/server.log"
> > > +
> > > +$QEMU_IMG info --image-opts \
> > > +    --object tls-creds-x509,dir=${tls_dir}/client1,endpoint=client,id=tls0 \
> > > +    driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0
> > > +
> > > +$QEMU_IMG info --image-opts \
> > > +    --object tls-creds-x509,dir=${tls_dir}/client3,endpoint=client,id=tls0 \
> > > +    driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0
> > 
> > Similarly, do we want --list testing here?
> 
> I'll have a look.

For same reason as above, we don't need to repeat with qemu-nbd --list

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2019-02-27 15:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 11:51 [Qemu-devel] [PATCH v5 0/2] nbd: support for authorization control on TLS connections Daniel P. Berrangé
2019-02-27 11:51 ` [Qemu-devel] [PATCH v5 1/2] qemu-nbd: add support for authorization of TLS clients Daniel P. Berrangé
2019-02-27 14:25   ` Eric Blake
2019-02-27 15:33     ` Daniel P. Berrangé
2019-02-27 15:58       ` Daniel P. Berrangé [this message]
2019-02-27 16:32         ` Eric Blake
2019-02-27 11:51 ` [Qemu-devel] [PATCH v5 2/2] nbd: allow authorization with nbd-server-start QMP command Daniel P. Berrangé
2019-02-27 14:30   ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190227155828.GO31688@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.