From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:45259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzQ9f-00069T-Ua for qemu-devel@nongnu.org; Thu, 28 Feb 2019 13:11:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gzQ9c-0007X8-02 for qemu-devel@nongnu.org; Thu, 28 Feb 2019 13:11:33 -0500 References: <20190227162035.18543-1-berrange@redhat.com> <20190227162035.18543-2-berrange@redhat.com> From: Eric Blake Message-ID: Date: Thu, 28 Feb 2019 12:11:00 -0600 MIME-Version: 1.0 In-Reply-To: <20190227162035.18543-2-berrange@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 1/3] qemu-nbd: add support for authorization of TLS clients List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , qemu-devel@nongnu.org Cc: "Dr. David Alan Gilbert" , Kevin Wolf , Markus Armbruster , qemu-block@nongnu.org, Max Reitz , Juan Quintela On 2/27/19 10:20 AM, Daniel P. Berrang=C3=A9 wrote: > From: "Daniel P. Berrange" >=20 > Currently any client which can complete the TLS handshake is able to us= e > 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. >=20 > This adds a '--tls-authz OBJECT-ID' option to the qemu-nbd command whic= h > 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. It doesn't hold up this patch, but I note that with the qemu QMP command changes you make in 2/3, you document that the object can be created/removed on the fly, and the server will adjust which clients can then subsequently connect. Is there any need for the same sort of runtime configurability in qemu-nbd, and if so, how would we accomplish it? Perhaps by having a command-line option to parse --tls-authz from a file, where you can send SIGHUP to qemu-nbd to force it to re-read the file? Or am I worrying about something unlikely to be needed in practice= ? --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org