On Fri, Jul 24, 2009 at 12:19:22AM -0400, Miloslav Trmac wrote:

----- "Daniel P. Berrange" <berrange@redhat.com> wrote:

...

On Tue, Jul 21, 2009 at 01:11:58PM +0200, Miloslav Trma?? wrote:

...

Note that partial encryption information (e.g. specifying an encryption format, but not the key/passphrase) is valid: * virStorageVolGetXMLDesc() will never reveal the key/passphrase, even if known by libvirt.

I don't think that restriction really adds anything in the scenario that we're using domain XML files for persistent storage of keys.

The patches leave this decision to the client: the client might decide not to use persistent domains. In any case, allowing the node to store the secrets locally does not imply that anyone that can connect to the node read-write can access the secrets - or does it?

In general all libvirt clients have the same privileges, the only restriction being local read-only clients. Basically if a client authenticates read-write then they can access / modify all objects managed on that host. In the future we will introduce fine grained access control down to a level of (user, object, operation).

...

eg, if domain XML lets you see passphrases, then vol XML should too (given a suitable VIR_STORAGE_VOL_SECURE flag).

Domain XML should not allow returning the secrets either, because domain migration lets other nodes connect read-write - see [0/9] for more details.

We have to allow returning the secrets, because clients need to be able to round-trip the XML without loosing data, eg xml = virDomainGetXMLDesc(dom, VIR_DOMAIN_XML_INACTIVE | VIR_DOMAIN_XML_SECURE) ...modify xml... virDomainDefineXML(conn, xml) must not loose any data, including the secrets.

...

...

* Future mechanisms could be set up to allow a libvirt user to specify during volume creation that a volume should be encrypted, leaving libvirt to choose suitable parameters and key and return them: this would allow the libvirt user to automatically support any encryption parameters (and perhaps encryption formats) supported in libvirt, as long as the user can send the same information back when using the volume in the future.

We could allow this now without extra APIs, if we let virStorageVolGetXML show the ke/passphrase given a new VIR_STORAGE_VOL_SECURE flag.

That is racy with respect to pool refresh, and gives other clients than the node creator (again, other nodes) access to the secrets - again, see [0/9].

Allowing other clients access to the secrets is fine - all authenticated clients are considered equal. We shouldn't try to define restrictions on this specifically for disk encryption, as fine grained per-client access control will be introduced across the whole of libvirt at a later date. There is a small race wrt to pool refresh, however, in the scenario of not using a keystore, this is an acceptable limitation IMHO. If using a keystore, then libvirt can associate a key ID with a volume and maintain that mapping long term, and reliably pass the actual secrets about internally. 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 :|