From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHnaL-0003vl-PE for qemu-devel@nongnu.org; Fri, 16 Dec 2016 03:09:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHnaK-00028X-KK for qemu-devel@nongnu.org; Fri, 16 Dec 2016 03:09:45 -0500 Received: from mail-it0-x242.google.com ([2607:f8b0:4001:c0b::242]:33895) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cHnaK-00027V-DU for qemu-devel@nongnu.org; Fri, 16 Dec 2016 03:09:44 -0500 Received: by mail-it0-x242.google.com with SMTP id 75so1746338ite.1 for ; Fri, 16 Dec 2016 00:09:43 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Stefan Hajnoczi Date: Fri, 16 Dec 2016 08:09:41 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Buddhi Madhav Cc: ashish mittal , Ketan Nilangekar , Paolo Bonzini , "Daniel P. Berrange" , Jeff Cody , qemu-devel , Kevin Wolf , Markus Armbruster , Fam Zheng , Ashish Mittal , Abhijit Dey , "Venkatesha M.G." , Nitin Jerath , Gaurav Bhandarkar , Abhishek Kane , Ketan Mahajan , Niranjan Pendharkar , Nirendra Awasthi , Rakesh Ranjan On Fri, Dec 16, 2016 at 1:42 AM, Buddhi Madhav wrote: > Does this authentication scheme works? > > 1) Pass the encrypted password to qemu-kvm as follows: > > # . /qemu-io --object secret,id=secmaster0,format=base64,file=key.b64 > --object secret,id=password-secret,keyid=secmaster0,file=pw.aes,iv=$( > 2) QEMU process will decrypt the password. (call qcrypto_secret_lookup_as_utf8()). I'm not sure if AES encrypting the password secret file adds anything. If an attacker is able to read pw.aes they can also read key.b64 and see the initialization vector on the command-line (using ps(1)). Therefore they would be able to decrypt the password. The main benefit of using -object secret,file= is to limit access to the secret via UNIX file permissions and to prevent exposing the secret on the command-line. You get those benefits without AES: --object secret,id=password-secret,file=pw Dan: Am I missing something? > 3) For every disk open, QEMU process sends VM ID, vdisk ID, and decrypted password. Hyperscale server > validates the password, and sends back the access token(unique 32bit ID). Two issues: 1. This is secure only if the transport offers confidentiality (e.g. encryption over TCP). Otherwise an attacker can intercept the traffic and steal the decrypted password. 2. This is secure only if the client authenticates the server. Otherwise the server could be a man-in-the-middle that steals the password. Your scheme is secure over AF_UNIX where the UNIX domain socket is located in a directory where only the real server process has permission to create files. AF_UNIX cannot be intercepted by external attackers or unprivileged users, so the transport offers confidentiality. This scheme is not secure over TCP/IP/Ethernet since the server is not being authenticated and there is no confidentiality. Are there network protocol and security folks at Veritas who can advise you? This isn't a QEMU-specific issue, it's a VxHS network protocol issue. You need to choose a modern, secure approach to networking. Stefan