[libvirt] [PATCH 2/4] qemu: Introduce qemuBuildSecretObjectProps

[Daniel P. Berrange]

On Wed, Jun 01, 2016 at 11:11:40AM -0400, John Ferlan wrote:
> 
> 
> On 06/01/2016 09:10 AM, Daniel P. Berrange wrote:
> > On Wed, Jun 01, 2016 at 09:04:00AM -0400, John Ferlan wrote:
> >> My quandary is less about the qemu-img infrastructure than the storage
> >> driver code.
> >>
> >> That is, it's "less clear" in my mind how the storage_backend.c code
> >> would need to handle a ",file=" for its short lived master key. Where to
> >> create the file?  What issues around permissions will there be?
> >> Basically anything that virSecurityManagerDomainSetPathLabel handles for
> >> the domain master key. I've been working under the assumption that it'll
> >> need to be done, but hadn't quite got that far yet.
> > 
> > I see three possible options
> > 
> >  1 Have storage driver create a random master key when libvirtd starts up
> >    and use that with all qemu-img invokations
> > 
> >  2 Have storage driver create a random master key per pool and use that
> >    with all qemu-img invokations against that pool
> > 
> 
> I wasn't thinking that this key would need to be stored long term,
> although I suppose that works too using the driver->stateDir as the
> location and building the file name using master-key.aes.
> 
> I had been leaning towards generating it on the fly as needed. It was
> more the mgmt of the file for what amounts to one operation. Of course
> while typing and thinking generating a temporary file on the fly has
> drawbacks too.
> 
> >  3 Ignore master keys entirely and just put the encryption key for the
> >    luks volume in a file directly. ie just one secret object using file=
> >    instead of two secret objects
> > 
> 
> Just to be clear - the key could be base64 encoded raw text in a file?
> Or just the raw text in a file. Too bad we couldn't link to the secret
> driver file directly...
> 
> In either case it's still not clear what protections are sufficient.
> That is would there need to be a virSecurityManagerDomainSetPathLabel
> type call in order for qemu-img to use the file or would creating the
> file in driver->stateDir be sufficient?

Yep, using a master secret does not really buy us any benefit when
using qemu-img in one-shot mode. The main rational for the master
secret feature was to facilitate QEMU hotplug, so that you could
securely pass secrets to a running QEMU without having to create
files on disk for every single secret you pass over the QMP monitor.

With qemu-img being a short-lived process doing individual specific
tasks, it is fine to just save the real secret on disk in either
raw or base64 format, and directly reference it without using a
master secret. In terms of permissions it is sufficient to make
sure the file is simply -r------- & owned by the uid/gid that we're
invoking qemu-img under.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|