| Message ID | 1457636396-24983-7-git-send-email-berrange@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 03/10/2016 11:59 AM, Daniel P. Berrange wrote: > 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 weak bar. > > This adds a '--tls-acl ACL-ID' option to the qemu-nbd command > which takes the ID of a previously added 'QAuthZ' object > instance. This ACL will be used to validate the client's > x509 distinguished name. Clients failing the ACL will not be > permitted to use the NBD server. > > For example to setup an ACL 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=acl0,policy=deny,\ > rules.0.match=*CN=fred,rules.0.policy=allow \ > -tls-creds tls0 \ > -tls-acl acl0 > ....other qemu-nbd args... Ah, so you are arguing that this is feature-completion of work started in 2.6, continuing work started before soft-freeze, and not a new feature to be delayed to 2.7. > > Signed-off-by: Daniel P. Berrange <berrange@redhat.com> > --- > qemu-nbd.c | 13 ++++++++++++- > qemu-nbd.texi | 4 ++++ > 2 files changed, 16 insertions(+), 1 deletion(-) > > +++ b/qemu-nbd.texi > @@ -86,6 +86,10 @@ the new style NBD protocol negotiation > Enable mandatory TLS encryption for the server by setting the ID > of the TLS credentials object previously created with the --object > option. > +@item --tls-acl=ID > +Specify the ID of a qauthz object previously created with the > +--object option. This will be used to authorize users who > +connect against their x509 distinguish name. s/distinguish/distinguished/ Reviewed-by: Eric Blake <eblake@redhat.com>
On Tue, Mar 22, 2016 at 12:14:27PM -0600, Eric Blake wrote: > On 03/10/2016 11:59 AM, Daniel P. Berrange wrote: > > 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 weak bar. > > > > This adds a '--tls-acl ACL-ID' option to the qemu-nbd command > > which takes the ID of a previously added 'QAuthZ' object > > instance. This ACL will be used to validate the client's > > x509 distinguished name. Clients failing the ACL will not be > > permitted to use the NBD server. > > > > For example to setup an ACL 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=acl0,policy=deny,\ > > rules.0.match=*CN=fred,rules.0.policy=allow \ > > -tls-creds tls0 \ > > -tls-acl acl0 > > ....other qemu-nbd args... > > Ah, so you are arguing that this is feature-completion of work started > in 2.6, continuing work started before soft-freeze, and not a new > feature to be delayed to 2.7. Yes and v1 of this patch series was in fact posted just a few days before the soft-freeze deadline. That said, as mentioned in the earlier patch, I'm open minded about whether this goes in 2.6 or 2.7. It would be nice to have in 2.6 but not the end of the world if it misses it, as overall we're still waaaaaaaay better off compared to 2.5 even if this doesn't mege :-) Regards, Daniel
diff --git a/qemu-nbd.c b/qemu-nbd.c index a5c1d95..d70960f 100644 --- a/qemu-nbd.c +++ b/qemu-nbd.c @@ -42,6 +42,7 @@ #define QEMU_NBD_OPT_OBJECT 260 #define QEMU_NBD_OPT_TLSCREDS 261 #define QEMU_NBD_OPT_IMAGE_OPTS 262 +#define QEMU_NBD_OPT_TLSACL 263 static NBDExport *exp; static bool newproto; @@ -55,6 +56,7 @@ static int nb_fds; static QIOChannelSocket *server_ioc; static int server_watch = -1; static QCryptoTLSCreds *tlscreds; +static const char *tlsacl; static void usage(const char *name) { @@ -344,7 +346,7 @@ static gboolean nbd_accept(QIOChannel *ioc, GIOCondition cond, gpointer opaque) nb_fds++; nbd_update_server_watch(); nbd_client_new(newproto ? NULL : exp, cioc, - tlscreds, NULL, nbd_client_closed); + tlscreds, tlsacl, nbd_client_closed); object_unref(OBJECT(cioc)); return TRUE; @@ -488,6 +490,7 @@ int main(int argc, char **argv) { "export-name", required_argument, NULL, 'x' }, { "tls-creds", required_argument, NULL, QEMU_NBD_OPT_TLSCREDS }, { "image-opts", no_argument, NULL, QEMU_NBD_OPT_IMAGE_OPTS }, + { "tls-acl", no_argument, NULL, QEMU_NBD_OPT_TLSACL }, { NULL, 0, NULL, 0 } }; int ch; @@ -689,6 +692,9 @@ int main(int argc, char **argv) case QEMU_NBD_OPT_IMAGE_OPTS: imageOpts = true; break; + case QEMU_NBD_OPT_TLSACL: + tlsacl = optarg; + break; } } @@ -725,6 +731,11 @@ int main(int argc, char **argv) error_get_pretty(local_err)); exit(EXIT_FAILURE); } + } else { + if (tlsacl) { + error_report("--tls-acl is not permitted without --tls-creds"); + exit(EXIT_FAILURE); + } } if (disconnect) { diff --git a/qemu-nbd.texi b/qemu-nbd.texi index 9f23343..69f32cb 100644 --- a/qemu-nbd.texi +++ b/qemu-nbd.texi @@ -86,6 +86,10 @@ the new style NBD protocol negotiation Enable mandatory TLS encryption for the server by setting the ID of the TLS credentials object previously created with the --object option. +@item --tls-acl=ID +Specify the ID of a qauthz object previously created with the +--object option. This will be used to authorize users who +connect against their x509 distinguish name. @item -v, --verbose Display extra debugging information @item -h, --help
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 weak bar. This adds a '--tls-acl ACL-ID' option to the qemu-nbd command which takes the ID of a previously added 'QAuthZ' object instance. This ACL will be used to validate the client's x509 distinguished name. Clients failing the ACL will not be permitted to use the NBD server. For example to setup an ACL 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=acl0,policy=deny,\ rules.0.match=*CN=fred,rules.0.policy=allow \ -tls-creds tls0 \ -tls-acl acl0 ....other qemu-nbd args... Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- qemu-nbd.c | 13 ++++++++++++- qemu-nbd.texi | 4 ++++ 2 files changed, 16 insertions(+), 1 deletion(-)