[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Verita

From: Ketan Nilangekar
Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
Date: Fri, 18 Nov 2016 10:57:00 +0000
User-agent: Microsoft-MacOutlook/

On 11/18/16, 3:32 PM, "Stefan Hajnoczi" <address@hidden> wrote:

>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, do you have any details on the authentication implemented by qemu-nbd 
as part of the nbd protocol?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]