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? Assuming that the ownership, protection, and other security objects I have in my environment will work in all the various environments hasn't worked well. Tks - John > I think any of these are valid approachs really, so pick whatever you > think fits best > >> FWIW: The current "working" plan is a command such as: >> >> qemu-img create -f luks \ >> --object secret,id=m0,file=$FILE \ >> --object secret,id=s0,data=$SECRET,keyid=m0,iv=$IV,format=base64 \ >> -o key-secret=s0 $LUKSFILE $SIZE > > That's certainly a valid cli arg set if you pick my options 1/2 above > >> >> Thanks for the feedback so far... trying to make sure I don't get too >> far off into the weeds and the dog just keeps looking at me like I'm >> crazy when I ask her. > > Regards, > Daniel > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list