On Fri, Jul 24, 2009 at 12:19:22AM -0400, Miloslav Trmac wrote:
> ----- "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list