Re: [Qemu-block] [PATCH 1/6] qemu-nbd: add support for authorization of TLS clients

[Eric Blake]

On 06/15/2018 10:50 AM, Daniel P. Berrangé wrote:
> From: "Daniel P. Berrange" <address@hidden>
>
> 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 contains 'CN=fred', you would
> use:
>
>    qemu-nbd -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
>                     endpoint=server,verify-peer=yes \
>             -object authz-simple,id=authz0,policy=deny,\
>                    rules.0.match=*CN=fred,rules.0.policy=allow \

s/-object/--object/g

>             -tls-creds tls0 \
>             -tls-authz authz0

s/-tls/--tls/g

(qemu-nbd requires double-dash long-opts, -o means --offset except that 
'bject' is not an offset; similarly for -t meaning --persistent)

>            ....other qemu-nbd args...
>
> Signed-off-by: Daniel P. Berrange <address@hidden>
> ---
>   include/block/nbd.h |  2 +-
>   nbd/server.c        | 12 +++++++-----
>   qemu-nbd.c          | 13 ++++++++++++-
>   qemu-nbd.texi       |  4 ++++
>   4 files changed, 24 insertions(+), 7 deletions(-)

> +++ b/nbd/server.c

> @@ -2153,7 +2153,9 @@ void nbd_client_new(NBDExport *exp,
>       if (tlscreds) {
>           object_ref(OBJECT(client->tlscreds));
>       }
> -    client->tlsaclname = g_strdup(tlsaclname);
> +    if (tlsauthz) {
> +        client->tlsauthz = g_strdup(tlsauthz);
> +    }

The 'if' is pointless; g_strdup(NULL) is safe.


> +++ b/qemu-nbd.c

> @@ -533,6 +535,7 @@ int main(int argc, char **argv)
>           { "image-opts", no_argument, NULL, QEMU_NBD_OPT_IMAGE_OPTS },
>           { "trace", required_argument, NULL, 'T' },
>           { "fork", no_argument, NULL, QEMU_NBD_OPT_FORK },
> +        { "tls-authz", no_argument, NULL, QEMU_NBD_OPT_TLSAUTHZ },

Not your fault, but worth sorting these alphabetically?

Bummer that pre-patch, you could use '--tls' as an unambiguous 
abbreviation for --tls-creds; now it is an ambiguous prefix (you have to 
type --tls-c or --tls-a to get to the point of no ambiguity).  If we 
really cared, we could add:

{ "t", required_argument, NULL, QEMU_NBD_OPT_TLSCREDS },
{ "tl", required_argument, NULL, QEMU_NBD_OPT_TLSCREDS },
{ "tls", required_argument, NULL, QEMU_NBD_OPT_TLSCREDS },
{ "tls-", required_argument, NULL, QEMU_NBD_OPT_TLSCREDS },

since getopt_long() no longer reports ambiguity if there is an exact 
match to what is otherwise the common prefix of two ambiguous options. 
But I don't think backwards-compatibility on this front is worth 
worrying about (generally, scripts don't rely on getopt_long()'s 
unambiguous prefix handling).

> +++ b/qemu-nbd.texi
> @@ -91,6 +91,10 @@ of the TLS credentials object previously created with the 
> --object
>   option.
>   @item --fork
>   Fork off the server process and exit the parent once the server is running.
> address@hidden --tls-authz=ID
> +Specify the ID of a qauthz object previously created with the

s/qauthz/authz-simple/ ?

> +--object option. This will be used to authorize users who
> +connect against their x509 distinguished name.

Sounds like someone is "connecting against their name", rather than 
"authorizing against their name".  Better might be:

This will be used to authorize connecting users against their x509 
distinguished name.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org