On 04/13/2018 02:26 PM, Nir Soffer wrote: > When a management application expose images using qemu-nbd, it needs a > secure way to allow temporary access to the disk. Using a random export > name can solve this problem: > > nbd://server:10809/22965f19-9ab5-4d18-94e1-cbeb321fa433
I share Dan's concerns that you are trying to protect information without requiring TLS. If you would just use TLS, then only clients that can authenticate can list the export names; the fact that the name leaks at all means you aren't using TLS, so you are just as vulnerable to a man-in-the-middle attack as you are to the information leak. > > Assuming that the url is passed to the user in a secure way, and the > user is using TLS to access the image. > > However, since qemu-nbd implements NBD_OPT_LIST, anyone can easily find > the secret export: > > $ nbd-client -l server 10809 > Negotiation: .. > 22965f19-9ab5-4d18-94e1-cbeb321fa433 If the server requires TLS, then 'nbd-client -l' already cannot list names without first negotiating TLS (all commands other than NBD_OPT_STARTTLS are rejected with NBD_REP_ERR_TLS_REQD if the server required TLS). Your example is thus invalidating your above assumption that the user is using TLS. > > Add a new --nolist option, disabling listing, similar the "allowlist" > nbd-server configuration option. This may still make sense to implement, but not necessarily for the reasons you are giving. > @@ -86,6 +88,7 @@ static void usage(const char *name) > " -v, --verbose display extra debugging information\n" > " -x, --export-name=NAME expose export by name\n" > " -D, --description=TEXT with -x, also export a human-readable > description\n" > +" --nolist do not list export\n" s/export/exports/ -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
