2019-03-07 17:58:38 +03:00
|
|
|
#!/usr/bin/env bash
|
2021-01-16 16:44:19 +03:00
|
|
|
# group: quick
|
2018-11-16 18:53:25 +03:00
|
|
|
#
|
|
|
|
# Test NBD TLS certificate / authorization integration
|
|
|
|
#
|
2019-01-17 22:36:38 +03:00
|
|
|
# Copyright (C) 2018-2019 Red Hat, Inc.
|
2018-11-16 18:53:25 +03:00
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 2 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
#
|
|
|
|
|
|
|
|
# creator
|
|
|
|
owner=berrange@redhat.com
|
|
|
|
|
|
|
|
seq=$(basename $0)
|
|
|
|
echo "QA output created by $seq"
|
|
|
|
|
|
|
|
status=1 # failure is the default!
|
|
|
|
|
|
|
|
_cleanup()
|
|
|
|
{
|
|
|
|
nbd_server_stop
|
|
|
|
_cleanup_test_img
|
2019-02-20 17:58:18 +03:00
|
|
|
# If we aborted early we want to see this log for diagnosis
|
|
|
|
test -f "$TEST_DIR/server.log" && cat "$TEST_DIR/server.log"
|
2019-01-17 22:36:38 +03:00
|
|
|
rm -f "$TEST_DIR/server.log"
|
2018-11-16 18:53:25 +03:00
|
|
|
tls_x509_cleanup
|
|
|
|
}
|
|
|
|
trap "_cleanup; exit \$status" 0 1 2 3 15
|
|
|
|
|
|
|
|
# get standard environment, filters and checks
|
|
|
|
. ./common.rc
|
|
|
|
. ./common.filter
|
|
|
|
. ./common.pattern
|
|
|
|
. ./common.tls
|
|
|
|
. ./common.nbd
|
|
|
|
|
|
|
|
_supported_fmt raw qcow2
|
|
|
|
_supported_proto file
|
|
|
|
# If porting to non-Linux, consider using socat instead of ss in common.nbd
|
|
|
|
_require_command QEMU_NBD
|
|
|
|
|
|
|
|
tls_x509_init
|
|
|
|
|
|
|
|
echo
|
|
|
|
echo "== preparing TLS creds =="
|
|
|
|
|
|
|
|
tls_x509_create_root_ca "ca1"
|
|
|
|
tls_x509_create_root_ca "ca2"
|
|
|
|
tls_x509_create_server "ca1" "server1"
|
|
|
|
tls_x509_create_client "ca1" "client1"
|
|
|
|
tls_x509_create_client "ca2" "client2"
|
qemu-nbd: add support for authorization of TLS clients
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.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-27 19:20:33 +03:00
|
|
|
tls_x509_create_client "ca1" "client3"
|
2018-11-16 18:53:25 +03:00
|
|
|
|
|
|
|
echo
|
|
|
|
echo "== preparing image =="
|
|
|
|
_make_test_img 64M
|
2018-11-18 05:24:03 +03:00
|
|
|
$QEMU_IO -c 'w -P 0x11 1m 1m' "$TEST_IMG" | _filter_qemu_io
|
2018-11-16 18:53:25 +03:00
|
|
|
|
|
|
|
echo
|
|
|
|
echo "== check TLS client to plain server fails =="
|
2019-01-17 22:36:38 +03:00
|
|
|
nbd_server_start_tcp_socket -f $IMGFMT "$TEST_IMG" 2> "$TEST_DIR/server.log"
|
2018-11-16 18:53:25 +03:00
|
|
|
|
2019-01-17 22:36:58 +03:00
|
|
|
obj=tls-creds-x509,dir=${tls_dir}/client1,endpoint=client,id=tls0
|
|
|
|
$QEMU_IMG info --image-opts --object $obj \
|
2018-11-16 18:53:25 +03:00
|
|
|
driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
|
|
|
|
2>&1 | sed "s/$nbd_tcp_port/PORT/g"
|
2019-01-17 22:36:58 +03:00
|
|
|
$QEMU_NBD_PROG -L -b $nbd_tcp_addr -p $nbd_tcp_port --object $obj \
|
|
|
|
--tls-creds=tls0
|
2018-11-16 18:53:25 +03:00
|
|
|
|
|
|
|
nbd_server_stop
|
|
|
|
|
|
|
|
echo
|
|
|
|
echo "== check plain client to TLS server fails =="
|
|
|
|
|
2018-11-20 20:56:46 +03:00
|
|
|
nbd_server_start_tcp_socket \
|
2020-11-04 16:57:21 +03:00
|
|
|
--object tls-creds-x509,dir=${tls_dir}/server1,endpoint=server,id=tls0,verify-peer=on \
|
2018-11-20 20:56:46 +03:00
|
|
|
--tls-creds tls0 \
|
2019-01-17 22:36:38 +03:00
|
|
|
-f $IMGFMT "$TEST_IMG" 2>> "$TEST_DIR/server.log"
|
2018-11-16 18:53:25 +03:00
|
|
|
|
|
|
|
$QEMU_IMG info nbd://localhost:$nbd_tcp_port 2>&1 | sed "s/$nbd_tcp_port/PORT/g"
|
2019-01-17 22:36:58 +03:00
|
|
|
$QEMU_NBD_PROG -L -b $nbd_tcp_addr -p $nbd_tcp_port
|
2018-11-16 18:53:25 +03:00
|
|
|
|
|
|
|
echo
|
|
|
|
echo "== check TLS works =="
|
qemu-nbd: add support for authorization of TLS clients
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.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-27 19:20:33 +03:00
|
|
|
obj1=tls-creds-x509,dir=${tls_dir}/client1,endpoint=client,id=tls0
|
|
|
|
obj2=tls-creds-x509,dir=${tls_dir}/client3,endpoint=client,id=tls0
|
|
|
|
$QEMU_IMG info --image-opts --object $obj1 \
|
2018-11-16 18:53:25 +03:00
|
|
|
driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
|
|
|
|
2>&1 | sed "s/$nbd_tcp_port/PORT/g"
|
qemu-nbd: add support for authorization of TLS clients
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.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-27 19:20:33 +03:00
|
|
|
$QEMU_IMG info --image-opts --object $obj2 \
|
|
|
|
driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
|
|
|
|
2>&1 | sed "s/$nbd_tcp_port/PORT/g"
|
|
|
|
$QEMU_NBD_PROG -L -b $nbd_tcp_addr -p $nbd_tcp_port --object $obj1 \
|
2019-01-17 22:36:58 +03:00
|
|
|
--tls-creds=tls0
|
2018-11-16 18:53:25 +03:00
|
|
|
|
|
|
|
echo
|
|
|
|
echo "== check TLS with different CA fails =="
|
2019-01-17 22:36:58 +03:00
|
|
|
obj=tls-creds-x509,dir=${tls_dir}/client2,endpoint=client,id=tls0
|
|
|
|
$QEMU_IMG info --image-opts --object $obj \
|
2018-11-16 18:53:25 +03:00
|
|
|
driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
|
|
|
|
2>&1 | sed "s/$nbd_tcp_port/PORT/g"
|
2019-01-17 22:36:58 +03:00
|
|
|
$QEMU_NBD_PROG -L -b $nbd_tcp_addr -p $nbd_tcp_port --object $obj \
|
|
|
|
--tls-creds=tls0
|
2018-11-16 18:53:25 +03:00
|
|
|
|
2018-11-18 05:24:03 +03:00
|
|
|
echo
|
|
|
|
echo "== perform I/O over TLS =="
|
|
|
|
QEMU_IO_OPTIONS=$QEMU_IO_OPTIONS_NO_FMT
|
|
|
|
$QEMU_IO -c 'r -P 0x11 1m 1m' -c 'w -P 0x22 1m 1m' --image-opts \
|
|
|
|
--object tls-creds-x509,dir=${tls_dir}/client1,endpoint=client,id=tls0 \
|
|
|
|
driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
|
|
|
|
2>&1 | _filter_qemu_io
|
|
|
|
|
2018-11-20 20:56:46 +03:00
|
|
|
$QEMU_IO -f $IMGFMT -r -U -c 'r -P 0x22 1m 1m' "$TEST_IMG" | _filter_qemu_io
|
2018-11-18 05:24:03 +03:00
|
|
|
|
qemu-nbd: add support for authorization of TLS clients
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.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-27 19:20:33 +03:00
|
|
|
echo
|
|
|
|
echo "== check TLS with authorization =="
|
|
|
|
|
|
|
|
nbd_server_stop
|
|
|
|
|
|
|
|
nbd_server_start_tcp_socket \
|
2020-11-04 16:57:21 +03:00
|
|
|
--object tls-creds-x509,dir=${tls_dir}/server1,endpoint=server,id=tls0,verify-peer=on \
|
qemu-nbd: add support for authorization of TLS clients
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.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-27 19:20:33 +03:00
|
|
|
--object "authz-simple,id=authz0,identity=CN=localhost,, \
|
|
|
|
O=Cthulu Dark Lord Enterprises client1,,L=R'lyeh,,C=South Pacific" \
|
|
|
|
--tls-authz authz0 \
|
|
|
|
--tls-creds tls0 \
|
|
|
|
-f $IMGFMT "$TEST_IMG" 2>> "$TEST_DIR/server.log"
|
|
|
|
|
|
|
|
$QEMU_IMG info --image-opts \
|
|
|
|
--object tls-creds-x509,dir=${tls_dir}/client1,endpoint=client,id=tls0 \
|
2019-05-06 19:05:29 +03:00
|
|
|
driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
|
|
|
|
2>&1 | sed "s/$nbd_tcp_port/PORT/g"
|
qemu-nbd: add support for authorization of TLS clients
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.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-27 19:20:33 +03:00
|
|
|
|
|
|
|
$QEMU_IMG info --image-opts \
|
|
|
|
--object tls-creds-x509,dir=${tls_dir}/client3,endpoint=client,id=tls0 \
|
2019-05-06 19:05:29 +03:00
|
|
|
driver=nbd,host=$nbd_tcp_addr,port=$nbd_tcp_port,tls-creds=tls0 \
|
|
|
|
2>&1 | sed "s/$nbd_tcp_port/PORT/g"
|
qemu-nbd: add support for authorization of TLS clients
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.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-27 19:20:33 +03:00
|
|
|
|
2019-01-17 22:36:38 +03:00
|
|
|
echo
|
|
|
|
echo "== final server log =="
|
|
|
|
cat "$TEST_DIR/server.log"
|
2019-02-20 17:58:18 +03:00
|
|
|
rm -f "$TEST_DIR/server.log"
|
2019-01-17 22:36:38 +03:00
|
|
|
|
2018-11-16 18:53:25 +03:00
|
|
|
# success, all done
|
|
|
|
echo "*** done"
|
|
|
|
rm -f $seq.full
|
|
|
|
status=0
|