Re: [libvirt] [PATCH 2/4] qemu: Introduce qemuBuildSecretObjectProps
On Tue, May 31, 2016 at 12:47:52 -0400, John Ferlan wrote:
On 05/31/2016 10:10 AM, Peter Krempa wrote:
> On Tue, May 31, 2016 at 09:49:45 -0400, John Ferlan wrote:
>> On 05/31/2016 08:10 AM, Peter Krempa wrote:
[...]
>> >From that same 2.6 wiki pointer, you'll note that
the qemu-img format
>> for luks will utilize "--object secret..."... We currently have no
way
>> to have a secret luks could use, but that's what I'm working towards. I
>> have also found through experimentation that creating an AES/secinfo
>
> That sounds like a bug to me if it doesn't work.
>
Perhaps - only recently discovered though... have yet to determine
whether it was an expected way to provide the secret...
I'd say it makes sense to provide a secret that way. Especially since
you need it for disk hotplug of LUKS volumes where you need to
instantiate the secret objects via the monitor and in case of migration
then via the command line. I don't think it's desired to use unencrypted
secrets on the monitor though since it would require to use different
code to create them.
>> like secret won't work. So the options are
"raw" text, base64 encoded
>> raw text, or a file (with raw or base64 encoded text password contained).
>
> As said, first two are a non-option since it discloses the passphrase.
> File is an option but it requires setup to put it on disk with correct
> permissions and such which basically re-implemets the same thing we do
> for adding the master key. So basically it's desired to be able to do
> AES encrypted secrets for the LUKS key too.
>
True, "file" is essentially the methodology used for the domain master
key.... And furthermore qemuBuildMasterKeyCommandLine could be modified
to actually call this common routine rather than inline building the
"object secret,id=$ALIAS,format=raw,file=$FILE". In the case of the
master key - the contents of $FILE are the 32 bytes of random data.
I would think the storage_backend.c code should use the same "method" as
the qemu-kvm code in order to build the secret objects, don't you think?
It obviously cannot share the domain master key, it would have to
generate it's own. Trying to taking a logical approach to getting there
Thats more due to the fact that storage volumes are not inherently tied
to any domain so there isn't anything you could reuse.
though.
Regardless of the AES/luks anomaly I found, the purpose was to have a
common way to generate the same format whether being built for
qemu_command.c for qemu-kvm or storage_backend.c for qemu-img.
I can agree that "secret,id=$alias,data=$data" is unwanted from the
viewpoint of disclosing the raw secret on the command line; however,
it's still possible to create 32 random bytes and encode it and pass as
"data=$data,format=base64" (the example I've taken from the qemu code):
That depens on what you are trying to use the random bits for. If it's
for generating encryption keys they need to be treated the same as
passwords since the encryption keys are directly derived from them.
openssl rand -base64 32 > key.b64
Erm. How exactly is that not creating a temporary file?
KEY=$(base64 -d key.b64 | hexdump -v -e '/1
"%02X"')
semi-granted. environment variables are in fact kept somewhat secret
using unix permissions. (/proc/$PID/environ/ has 600 perms) but not
using selinux.
Also as a side effect, environment may be leaked to child processes
unless explicitly sanitized, whereas memory is by default sanitized.
So that one doesn't have to deal with the on disk file
permissions.
It's simple enough to ensure that "raw" data isn't accepted... It's
also
possible to ensure that someone providing a base64 encoded value to be
used for a master key would provide something valid.
Libvirt shall generate the master secret so why do you need to check
it?
Similarly for the contents of a file, it's simple enough to check
that
the length of data is proper for either raw or base64 encoding, if
that's desired. The whole file permissions wasn't as clear to me whether
the qemu-img needs to follow at least w/r/t security manager change made
in order to allow the domain secret key file to be used.
Why shouldn't it. As long as qemu-img supports the same infrastructure
for the secret objects then we should treat both equally including the
master key and commandline secret object instantiation.