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