| Message ID | 20190227115152.1906-2-berrange@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | nbd: support for authorization control on TLS connections | expand |
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. I'm half-tempted to propose a QemuOpts patch that eats whitespace after comma, to make examples like this actually valid command lines. (Actually, your example breaks line after an escaped comma, which would result in a literal 'identity=CN=..., O=Example...' option even if space is eaten, and I don't know if that forms a valid identity). But doesn't hold up this patch. > > Reviewed-by: Juan Quintela <quintela@redhat.com> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com> > --- > +++ b/qemu-nbd.c > + } else { > + if (tlsauthz) { > + error_report("--tls-authz is not permitted without --tls-creds"); > + exit(EXIT_FAILURE); > + } > } > > if (list) { --list is new compared to when you originally proposed this patch. Does anything need to be changed on that front? (That is, does --tls-authz make sense when qemu-nbd is used as a client to probe a remote server's advertisements, or is it a server-only setting where we need to enhance the --list mode to reject use of the option?) > diff --git a/qemu-nbd.texi b/qemu-nbd.texi > index d0c5182814..d45ed9e0a0 100644 > --- a/qemu-nbd.texi > +++ b/qemu-nbd.texi > @@ -117,6 +117,10 @@ option; or provide the credentials needed for connecting as a client > in list mode. > @item --fork > Fork off the server process and exit the parent once the server is running. > +@item --tls-authz=ID > +Specify the ID of a qauthz object previously created with the > +--object option. This will be used to authorize connecting users > +against their x509 distinguished name. > @item -v, --verbose > Display extra debugging information. > @item -h, --help qemu-nbd.texi now has examples (which it did not have when you first wrote the patch). I'd love it if your command line example from the commit message were also included in the examples section of the man page. > 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? > > 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? Overall the patch looks good, but I'm wondering if we want a v6 to address the items pointed out above, or if a followup patch is sufficient.
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. > > + } else { > > + if (tlsauthz) { > > + error_report("--tls-authz is not permitted without --tls-creds"); > > + exit(EXIT_FAILURE); > > + } > > } > > > > if (list) { > > --list is new compared to when you originally proposed this patch. Does > anything need to be changed on that front? (That is, does --tls-authz > make sense when qemu-nbd is used as a client to probe a remote server's > advertisements, or is it a server-only setting where we need to enhance > the --list mode to reject use of the option?) We should reject tls-creds when --list is set, since it only makes sense on the server side, not client. > > diff --git a/qemu-nbd.texi b/qemu-nbd.texi > > index d0c5182814..d45ed9e0a0 100644 > > --- a/qemu-nbd.texi > > +++ b/qemu-nbd.texi > > @@ -117,6 +117,10 @@ option; or provide the credentials needed for connecting as a client > > in list mode. > > @item --fork > > Fork off the server process and exit the parent once the server is running. > > +@item --tls-authz=ID > > +Specify the ID of a qauthz object previously created with the > > +--object option. This will be used to authorize connecting users > > +against their x509 distinguished name. > > @item -v, --verbose > > Display extra debugging information. > > @item -h, --help > > qemu-nbd.texi now has examples (which it did not have when you first > wrote the patch). I'd love it if your command line example from the > commit message were also included in the examples section of the man page. Ok. > > 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 > > > > > 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. > Overall the patch looks good, but I'm wondering if we want a v6 to > address the items pointed out above, or if a followup patch is sufficient. I'll do a v6 since there's still enough time before soft freeze. Regards, Daniel
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
On 2/27/19 9:58 AM, Daniel P. Berrangé wrote: >>>> 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. There's two things being validated in this test: does the server properly honor authorization (accepting/denying clients as appropriate), and does the client properly expose a way to pass correct credentials. You're right that once we've tested that the server can reject at least one client lacking credentials, we don't need any more negative tests (the server will reject any other client without credentials); and as long as both clients that we care about (qemu-img, qemu-nbd --list) have at least one positive test, then we've covered that each important client has a way to provide the required credentials. Okay, I can live with your claim that we have sufficient coverage, and don't need anything more with --list (for this test, where the server is accepting regardless of client certificate). >>>> +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 Here, it's a bit fuzzier - now that the server DOES require the client to use a correct certificate (you're showing that the server accepts client 1 but rejects client 2, because they used a different certificate). But, since client 1 is the same here as it was before, and the earlier test showed how to let qemu-nbd --list as client give the same credentials as before, I can also live with the notion that we don't need a --list test here (the server being stricter about certificates doesn't change that the client can still pass the correct certificate). Okay.
diff --git a/include/block/nbd.h b/include/block/nbd.h index 96cfb1d7d5..554f531c1a 100644 --- a/include/block/nbd.h +++ b/include/block/nbd.h @@ -325,7 +325,7 @@ void nbd_export_close_all(void); void nbd_client_new(QIOChannelSocket *sioc, QCryptoTLSCreds *tlscreds, - const char *tlsaclname, + const char *tlsauthz, void (*close_fn)(NBDClient *, bool)); void nbd_client_get(NBDClient *client); void nbd_client_put(NBDClient *client); diff --git a/nbd/server.c b/nbd/server.c index 0910d09a6d..8ddfd3e319 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -111,7 +111,7 @@ struct NBDClient { NBDExport *exp; QCryptoTLSCreds *tlscreds; - char *tlsaclname; + char *tlsauthz; QIOChannelSocket *sioc; /* The underlying data channel */ QIOChannel *ioc; /* The current I/O channel which may differ (eg TLS) */ @@ -686,7 +686,7 @@ static QIOChannel *nbd_negotiate_handle_starttls(NBDClient *client, tioc = qio_channel_tls_new_server(ioc, client->tlscreds, - client->tlsaclname, + client->tlsauthz, errp); if (!tioc) { return NULL; @@ -1348,7 +1348,7 @@ void nbd_client_put(NBDClient *client) if (client->tlscreds) { object_unref(OBJECT(client->tlscreds)); } - g_free(client->tlsaclname); + g_free(client->tlsauthz); if (client->exp) { QTAILQ_REMOVE(&client->exp->clients, client, next); nbd_export_put(client->exp); @@ -2425,7 +2425,7 @@ static coroutine_fn void nbd_co_client_start(void *opaque) */ void nbd_client_new(QIOChannelSocket *sioc, QCryptoTLSCreds *tlscreds, - const char *tlsaclname, + const char *tlsauthz, void (*close_fn)(NBDClient *, bool)) { NBDClient *client; @@ -2437,7 +2437,7 @@ void nbd_client_new(QIOChannelSocket *sioc, if (tlscreds) { object_ref(OBJECT(client->tlscreds)); } - client->tlsaclname = g_strdup(tlsaclname); + client->tlsauthz = g_strdup(tlsauthz); client->sioc = sioc; object_ref(OBJECT(client->sioc)); client->ioc = QIO_CHANNEL(sioc); diff --git a/qemu-nbd.c b/qemu-nbd.c index 00c07fd27e..0738073d95 100644 --- a/qemu-nbd.c +++ b/qemu-nbd.c @@ -58,6 +58,7 @@ #define QEMU_NBD_OPT_TLSCREDS 261 #define QEMU_NBD_OPT_IMAGE_OPTS 262 #define QEMU_NBD_OPT_FORK 263 +#define QEMU_NBD_OPT_TLSAUTHZ 264 #define MBR_SIZE 512 @@ -71,6 +72,7 @@ static int shared = 1; static int nb_fds; static QIONetListener *server; static QCryptoTLSCreds *tlscreds; +static const char *tlsauthz; static void usage(const char *name) { @@ -103,6 +105,7 @@ static void usage(const char *name) " --object type,id=ID,... define an object such as 'secret' for providing\n" " passwords and/or encryption keys\n" " --tls-creds=ID use id of an earlier --object to provide TLS\n" +" --tls-authz=ID use id of an earlier --object to provide authorization\n" " -T, --trace [[enable=]<pattern>][,events=<file>][,file=<file>]\n" " specify tracing options\n" " --fork fork off the server process and exit the parent\n" @@ -452,7 +455,7 @@ static void nbd_accept(QIONetListener *listener, QIOChannelSocket *cioc, nb_fds++; nbd_update_server_watch(); - nbd_client_new(cioc, tlscreds, NULL, nbd_client_closed); + nbd_client_new(cioc, tlscreds, tlsauthz, nbd_client_closed); } static void nbd_update_server_watch(void) @@ -643,6 +646,7 @@ int main(int argc, char **argv) { "export-name", required_argument, NULL, 'x' }, { "description", required_argument, NULL, 'D' }, { "tls-creds", required_argument, NULL, QEMU_NBD_OPT_TLSCREDS }, + { "tls-authz", required_argument, NULL, QEMU_NBD_OPT_TLSAUTHZ }, { "image-opts", no_argument, NULL, QEMU_NBD_OPT_IMAGE_OPTS }, { "trace", required_argument, NULL, 'T' }, { "fork", no_argument, NULL, QEMU_NBD_OPT_FORK }, @@ -862,6 +866,9 @@ int main(int argc, char **argv) g_free(trace_file); trace_file = trace_opt_parse(optarg); break; + case QEMU_NBD_OPT_TLSAUTHZ: + tlsauthz = optarg; + break; case QEMU_NBD_OPT_FORK: fork_process = true; break; @@ -940,6 +947,11 @@ int main(int argc, char **argv) error_get_pretty(local_err)); exit(EXIT_FAILURE); } + } else { + if (tlsauthz) { + error_report("--tls-authz is not permitted without --tls-creds"); + exit(EXIT_FAILURE); + } } if (list) { diff --git a/qemu-nbd.texi b/qemu-nbd.texi index d0c5182814..d45ed9e0a0 100644 --- a/qemu-nbd.texi +++ b/qemu-nbd.texi @@ -117,6 +117,10 @@ option; or provide the credentials needed for connecting as a client in list mode. @item --fork Fork off the server process and exit the parent once the server is running. +@item --tls-authz=ID +Specify the ID of a qauthz object previously created with the +--object option. This will be used to authorize connecting users +against their x509 distinguished name. @item -v, --verbose Display extra debugging information. @item -h, --help diff --git a/tests/qemu-iotests/233 b/tests/qemu-iotests/233 index fc345a1a46..4762c380cb 100755 --- a/tests/qemu-iotests/233 +++ b/tests/qemu-iotests/233 @@ -59,6 +59,7 @@ tls_x509_create_root_ca "ca2" tls_x509_create_server "ca1" "server1" tls_x509_create_client "ca1" "client1" tls_x509_create_client "ca2" "client2" +tls_x509_create_client "ca1" "client3" echo echo "== preparing image ==" @@ -91,11 +92,15 @@ $QEMU_NBD_PROG -L -b $nbd_tcp_addr -p $nbd_tcp_port echo 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 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 + echo echo "== final server log ==" cat "$TEST_DIR/server.log" diff --git a/tests/qemu-iotests/233.out b/tests/qemu-iotests/233.out index 6d45f3b230..5acbc13b54 100644 --- a/tests/qemu-iotests/233.out +++ b/tests/qemu-iotests/233.out @@ -6,6 +6,7 @@ Generating a self signed certificate... Generating a signed certificate... Generating a signed certificate... Generating a signed certificate... +Generating a signed certificate... == preparing image == Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 @@ -29,6 +30,10 @@ image: nbd://127.0.0.1:PORT file format: nbd virtual size: 64M (67108864 bytes) disk size: unavailable +image: nbd://127.0.0.1:PORT +file format: nbd +virtual size: 64M (67108864 bytes) +disk size: unavailable exports available: 1 export: '' size: 67108864 @@ -51,7 +56,13 @@ wrote 1048576/1048576 bytes at offset 1048576 read 1048576/1048576 bytes at offset 1048576 1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +== check TLS with authorization == +qemu-img: Could not open 'driver=nbd,host=127.0.0.1,port=10809,tls-creds=tls0': Failed to read option reply: Cannot read from TLS channel: Software caused connection abort +qemu-img: Could not open 'driver=nbd,host=127.0.0.1,port=10809,tls-creds=tls0': Failed to read option reply: Cannot read from TLS channel: Software caused connection abort + == final server log == qemu-nbd: option negotiation failed: Verify failed: No certificate was found. qemu-nbd: option negotiation failed: Verify failed: No certificate was found. +qemu-nbd: option negotiation failed: TLS x509 authz check for CN=localhost,O=Cthulhu Dark Lord Enterprises client1,L=R'lyeh,C=South Pacific is denied +qemu-nbd: option negotiation failed: TLS x509 authz check for CN=localhost,O=Cthulhu Dark Lord Enterprises client3,L=R'lyeh,C=South Pacific is denied *** done