Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

[Markus Armbruster <armbru@redhat.com>]

Ketan Nilangekar <Ketan.Nilangekar@veritas.com> writes:

> On 11/18/16, 12:56 PM, "Jeff Cody" <jcody@redhat.com> 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).
>
> Our auth scheme is based on network isolation at L2/L3 level.

Stefan already explained the trust model.  Since understanding it is
crucial to security work, let me use the opportunity to explain it once
more.

The guest is untrusted.  It interacts only with QEMU and, if enabled,
KVM.  KVM has a relatively small attack surface, but if the guest
penetrates it, game's over.  There's nothing we can do to mitigate.
QEMU has a much larger attack surface, but we *can* do something to
mitigate a compromise: nothing on the host trusts QEMU.  Second line of
defense.

A line of defense is as strong as its weakest point.  Adding an
interface between QEMU and the host that requires the host to trust QEMU
basically destroys the second line of defense.  That's a big deal.

You might argue that you don't require "the host" to trust, but only
your daemon (or whatever it is your driver talks to).  But that puts
that daemon in the same security domain as QEMU itself, i.e. it should
not be trusted by anything else on the host.  Now you have a second
problem.

If you rely on "network isolation at L2/L3 level", chances are
*everything* on this isolated network joins QEMU's security domain.  You
almost certainly need a separate isolated network per guest to have a
chance at being credible.  Even then, I'd rather not bet my own money on
it.

It's better to stick to the common trust model, and have *nothing* on
the host trust QEMU.

> If there is a simplified authentication mechanism which we can implement without imposing significant penalties on IO performance, please let us know and we will implement that if feasible.

Daniel already listed available mechanisms.