From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:46973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzQGu-0001Mi-T6 for qemu-devel@nongnu.org; Thu, 28 Feb 2019 13:19:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gzQGs-0002z7-Ma for qemu-devel@nongnu.org; Thu, 28 Feb 2019 13:19:03 -0500 Date: Thu, 28 Feb 2019 18:18:12 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Message-ID: <20190228181812.GJ9217@redhat.com> Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20190227162035.18543-1-berrange@redhat.com> <20190227162035.18543-2-berrange@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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: Eric Blake Cc: qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Kevin Wolf , Markus Armbruster , qemu-block@nongnu.org, Max Reitz , Juan Quintela On Thu, Feb 28, 2019 at 12:11:00PM -0600, Eric Blake wrote: > 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 = 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 certificat= e. > > 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 fair= ly > > low bar to cross. > >=20 > > This adds a '--tls-authz OBJECT-ID' option to the qemu-nbd command wh= ich > > takes the ID of a previously added 'QAuthZ' object instance. This wil= l > > be used to validate the client's x509 distinguished name. Clients > > failing the authorization check will not be permitted to use the NBD > > server. >=20 > It doesn't hold up this patch, but I note that with the qemu QMP comman= d > 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 ca= n > 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 practi= ce? Well the QAuthZListFile object type can store its contents in an external file that gets auto-reloaded upon inotify triggers from the main loop. The QAuthZPAM type can also be fairly dynamic depending on its backend. I think any single process is unlikely to need to switch between different object types, so this is good enough dynamic support. I can't help thinking we should add QMP to qemu-nbd one day though.... Regards, Daniel --=20 |: https://berrange.com -o- https://www.flickr.com/photos/dberran= ge :| |: https://libvirt.org -o- https://fstop138.berrange.c= om :| |: https://entangle-photo.org -o- https://www.instagram.com/dberran= ge :|