[Libguestfs] [PATCH 2/2] options: Allow multiple --key parameters and default keys.

[Richard W.M. Jones]

On Mon, Nov 18, 2019 at 12:11:15PM +0100, Pino Toscano wrote:
> On Saturday, 16 November 2019 09:33:21 CET Richard W.M. Jones wrote:
> > It's considerably more convenient for callers if they don't have to
> > store this mapping between opaque libguestfs device names (a concept
> > which is meaningless to most users and to the software which
> > orchestrates virt-v2v at scale), and keys.
> 
> We use devices already for various things, including partitions and
> (in this case) devices for keys. If you use libguestfs tools (virt-v2v
> included) then you need to care about them, so "callers are dumb" is
> not one of the best arguments you can come up with.

In practical terms this would mean IMS has to do a new round trip
where we would have to do libguestfs inspection on guests before they
are presented in the UI, which is a whole bunch of work, and I still
don't understand why this would be necessary.

> > Also there's no actual penalty to making this feature available, it's
> > a natural extension which falls out from the implementation, and it
> > doesn't affect performance unless the caller adds multiple --key
> > parameters.  It's also how LUKS itself works if you enable
> > decrypt_keyctl in crypttab.
> 
> This is not about performance or how LUKS works (which both are
> irrelevant for libguestfs users), but rather about explicitly specifying
> a secret only to its target.

In the case where you run virt-v2v --key --key ... then the secrets
are only passed to a single VM.  So even if it was possible for the VM
to capture these keys, it would only be capturing keys used by its own
disks.  I really don't understand what could be the problem with this.

> > > Also, this makes it possible so
> > > in case of two similar guests like:
> > > - /dev/sda1 with key "key1", and /dev/sda2 with key "key2"
> > > - /dev/sda1 with key "key2", and /dev/sda2 with key "key1"
> > > the above command like will work in the same way, with no indication of
> > > which key was successfully used for which device -- so you can silently
> > > swap the first guest for the second with no changes to the v2v command
> > > line...
> > 
> > I didn't understand this.  It seems an unlikely scenario in the first
> > place, and has no ill effects even if it does occur.
> 
> I disagree with your assessment. Let's say that the first guest gets a
> new encypted partition with coincidentally the same key as /dev/sda1:
> I do not want that with a wildcard --key that device is silently opened
> without the user acting and explicitly saying "this is the key for this
> device" -- even if it is the same as another device.

OK so I believe you are worried that someone uses the same --key
option against two different guests.  But how is that any different
from now?  They could still accidentally reuse a key between guests
even the way it works right now.

In any case I don't understand how the guest could capture or save the
key, so I don't understand what the specific danger is.

> > > What's the use case for this?
> > 
> > So that IMS doesn't have to collect an exact mapping between opaque
> > libguestfs device names and keys, which will require some user to have
> > to enter device names that they don't understand into a UI without any
> > making typos rather than just supplying a list of keys that apply to a
> > single guest.
> 
> Few things here:
> - if the UI does not help the user insert the proper mapping between
>   devices (which cloudforms already knows) and keys, then it's a
>   problem of the UI

The problem is cloudforms doesn't really know libguestfs device names.
It knows something about devices and partitions, but those are derived
from SSA not libguestfs.

> - users can make typos even with your solution

If they typo the passphrase I guess everyone will expect it not to
work.  The problem is if they typo "/dev/sda2" which they have no idea
about.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org