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

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.


>  - 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.


> 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 


 - 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. 

|: 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 :|

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