qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v6 1/3] qemu-nbd: add support for authorization


From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v6 1/3] qemu-nbd: add support for authorization of TLS clients
Date: Thu, 28 Feb 2019 12:11:00 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0

On 2/27/19 10:20 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.

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?

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]