All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v6 1/3] qemu-nbd: add support for authorization of TLS clients
Date: Thu, 28 Feb 2019 18:18:12 +0000	[thread overview]
Message-ID: <20190228181812.GJ9217@redhat.com> (raw)
In-Reply-To: <e6944ece-e00e-643a-fa71-deb18841e2fb@redhat.com>

On Thu, Feb 28, 2019 at 12:11:00PM -0600, Eric Blake wrote:
> On 2/27/19 10:20 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.
> 
> 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?

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
-- 
|: 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-28 18:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 16:20 [Qemu-devel] [PATCH v6 0/3] nbd: support for authorization control on TLS connections Daniel P. Berrangé
2019-02-27 16:20 ` [Qemu-devel] [PATCH v6 1/3] qemu-nbd: add support for authorization of TLS clients Daniel P. Berrangé
2019-02-27 16:43   ` Eric Blake
2019-02-27 16:50     ` Daniel P. Berrangé
2019-02-28 18:20     ` Eric Blake
2019-02-28 18:11   ` Eric Blake
2019-02-28 18:18     ` Daniel P. Berrangé [this message]
2019-02-28 18:27       ` Eric Blake
2019-02-27 16:20 ` [Qemu-devel] [PATCH v6 2/3] nbd: allow authorization with nbd-server-start QMP command Daniel P. Berrangé
2019-02-27 16:20 ` [Qemu-devel] [PATCH v6 3/3] nbd: fix outdated qapi docs syntax for tls-creds Daniel P. Berrangé
2019-02-27 16:44   ` Eric Blake
2019-02-28 18:41 ` [Qemu-devel] [PATCH v6 0/3] nbd: support for authorization control on TLS connections 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=20190228181812.GJ9217@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.