fd4a5fd463
Currently any client which can complete the TLS handshake is able to use a chardev 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 chardev server. This is still a fairly low bar. This adds a 'tls-authz=OBJECT-ID' option to the socket chardev backend 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 check will not be permitted to use the chardev server. For example to setup authorization that only allows connection from a client whose x509 certificate distinguished name contains 'CN=fred', you would use: $QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\ endpoint=server,verify-peer=yes \ -object authz-simple,id=authz0,identity=CN=laptop.example.com,,\ O=Example Org,,L=London,,ST=London,,C=GB \ -chardev socket,host=127.0.0.1,port=9000,server,\ tls-creds=tls0,tls-authz=authz0 \ ...other qemu args... Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> |
||
---|---|---|
.. | ||
authz.json | ||
block-core.json | ||
block.json | ||
char.json | ||
common.json | ||
crypto.json | ||
introspect.json | ||
job.json | ||
Makefile.objs | ||
migration.json | ||
misc.json | ||
net.json | ||
opts-visitor.c | ||
qapi-clone-visitor.c | ||
qapi-dealloc-visitor.c | ||
qapi-schema.json | ||
qapi-util.c | ||
qapi-visit-core.c | ||
qmp-dispatch.c | ||
qmp-event.c | ||
qmp-registry.c | ||
qobject-input-visitor.c | ||
qobject-output-visitor.c | ||
rdma.json | ||
rocker.json | ||
run-state.json | ||
sockets.json | ||
string-input-visitor.c | ||
string-output-visitor.c | ||
target.json | ||
tpm.json | ||
trace-events | ||
trace.json | ||
transaction.json | ||
ui.json |