[libvirt] [PATCH 2/9] Attach encryption information to virStorageVolDef.

[Daniel P. Berrange]

On Fri, Jul 24, 2009 at 12:19:22AM -0400, Miloslav Trmac wrote:
> ----- "Daniel P. Berrange" <berrange at 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 :|