Re: [libvirt] [PATCH 0/9] Add support for (qcow*) volume encryption
Replying to my own message...
On Fri, Jul 24, 2009 at 02:04:33PM +0100, Daniel P. Berrange wrote:
We also have to bear in mind how the MGMT server communicates
with the libvirt daemon. One likely option is using a messaging
service, which offers authenticity but not secrecy. ie, libvirt
receiving a request off the message bus can be sure the request
came from the mgmtm server, but cannot be sure it wasn't seen
by other users during transport. Thus by including secrets in
the XML, you could be exposing them to the message bus adminstrator.
[snip]
- A node can only see secrets for VMs it is configured to run
- MGMT server does not need to ever see the secrets itself. It
merely controls access for which nodes can see them, and can
request generation of new secrets
- Messages between the MGMT server & libvirtd do not need to
be encrypted, since they don't include secrets
- Other users who authenticate to libvirt on a node cannot
move a VM to an unauthorized node, since it can't see secrets
- VM save memory images (which include the fully XML) do not ever
expose the secrets. So VM save image cannot be restored on an
unauthorized node.
[snip]
one. I think it is very important that all these deployment
scenarios
can be supported without including the secrets in the XML config, since
there are faaaar too many ways in which the XML config itself may be
exposed to undesirable places.
Now that I look back on this, the implications of storing any passphrases
or secrets or keys in the XML are just horrific. There are soo many
places in which this data would leak out to untrusted sources. Just look
at virt-manager, virt-install, virsh, libvirtd, and indeed libvirt.so
itself. All of these tools have logging / debugging options which cause
the full XML docs of guest domains and storage volumes to be sent to
log files, or syslog. When debuging issues reported with bugzilla we
pretty much require that people provide logs from libvirt.so and apps
involved. This presents such an unacceptably high risk of compromising
secrets, that IMHO we not add any support in libvirt for storing secrets
in the XML whatsoever.
We should go straight for one of 2 options
- API for clients to directly create/delete/list/generate
And/or
- libvirtd backend that talks to a key sever to indirectly fetch secrets
And in the XML docs always reference keys based on a unique identifier
of some form.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|