[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: |
Wed, 1 Feb 2017 23:59:53 +0000 |
User-agent: |
Microsoft-MacOutlook/f.1c.1.161117 |
Patch for secure implementation in libqnio is available for review here:
https://github.com/VeritasHyperScale/libqnio/pull/12
libqnio client initialization now has an option to use X.509 certificates to
authenticate itself to the vxhs server.
Also each client IO request now includes an instance id that is used by the
vxhs server to authorize the request.
A test client has also been added.
Libqnio.so so is renamed to libvxhs.so. We will rename the repository once the
latest patches are merged.
QEMU patch to use the new secure interface will follow shortly.
Ketan.
On 12/16/16, 12:09 AM, "Stefan Hajnoczi" <address@hidden> wrote:
On Fri, Dec 16, 2016 at 1:42 AM, Buddhi Madhav
<address@hidden> 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=$(<iv.b64)
>
> 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
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support,
Ketan Nilangekar <=
Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Ketan Nilangekar, 2017/02/02