From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7fzv-00006A-EM for qemu-devel@nongnu.org; Fri, 18 Nov 2016 05:02:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7fzr-0007Si-IV for qemu-devel@nongnu.org; Fri, 18 Nov 2016 05:02:19 -0500 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:33175) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c7fzr-0007SI-Al for qemu-devel@nongnu.org; Fri, 18 Nov 2016 05:02:15 -0500 Received: by mail-wm0-x241.google.com with SMTP id u144so4472480wmu.0 for ; Fri, 18 Nov 2016 02:02:15 -0800 (PST) Date: Fri, 18 Nov 2016 10:02:10 +0000 From: Stefan Hajnoczi Message-ID: <20161118100210.GA28853@stefanha-x1.localdomain> References: <1475035789-685-1-git-send-email-ashish.mittal@veritas.com> <20160928214510.GA2837@stefanha-x1.localdomain> <20161118072621.GA2607@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20161118072621.GA2607@localhost.localdomain> Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: ashish mittal , qemu-devel , Paolo Bonzini , Kevin Wolf , Markus Armbruster , "Daniel P. Berrange" , Fam Zheng , Ashish Mittal , Ketan Nilangekar , Abhijit Dey , Buddhi.Madhav@veritas.com, Venkatesha.Mg@veritas.com --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 18, 2016 at 02:26:21AM -0500, Jeff Cody wrote: > * Daniel pointed out that there is no authentication method for taking to a > remote server. This seems a bit scary. Maybe all that is needed here is > some clarification of the security scheme for authentication? My > impression from above is that you are relying on the networks being > private to provide some sort of implicit authentication, though, and this > seems fragile (and doesn't protect against a compromised guest or other > process on the server, for one). Exactly, from the QEMU trust model you must assume that QEMU has been compromised by the guest. The escaped guest can connect to the VxHS server since it controls the QEMU process. An escaped guest must not have access to other guests' volumes. Therefore authentication is necessary. By the way, QEMU has a secrets API for providing passwords and other sensistive data without passing them on the command-line. The command-line is vulnerable to snooping by other processes so using this API is mandatory. Please see include/crypto/secret.h. Stefan --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYLtGiAAoJEJykq7OBq3PIJGEH/0TmHa64+wenw+hZloSq7nuv bkLMCssy0A5a72sqN+4LNq8TU1X3VRx3IBtO/vc74g4yLlh9438xePHUzHFH4Pnc nyMKw6tqpdm+aH5NN5wCdUnoEHq+QNKCEXJQXf9Vq0LvmM915XrBcR7nDk2oaEZX tDUixWHcACByqOe7GCYWlu47vQ670FMFd6QRAU0OeHPjRxxBHu6REPOPKr3UyC+s U5zp6of3XhR8DSfmEVLVVlRLJjWNoDSvf5yvWU7PauNT+gr82KtFteE0qPEbH+TF nTZdJFFM3u/Ou1+3Her+H7Lqs1ECnblxgWiqH7eUJV44K3aXchellXvjyty3++Y= =IlyG -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt--