[Libguestfs] [PATCH 2/2] Introduce a --key option in tools that accept keys

[Eric Blake]

On 9/19/18 5:37 AM, Pino Toscano wrote:
> The majority of the tools have already options (--echo-keys &
> --keys-from-stdin) to deal with LUKS credentials, although there is no
> way to automatically provide credentials.  --keys-from-stdin is
> suboptimal, because it is an usable solution only when there is just one

s/an/a/ (English is weird, the choice of 'a' or 'an' before a word 
beginning with 'u' depends on whether the pronunciation resembles soft 
'uh' [an umbrella] or hard 'yoo' [a unicorn]).

> device to open, and no other input passed via stdin to the tool (like
> the commands for guestfish).
> 
> To overcome this limitation, introduce a new --key option in tools:
> * --key /dev/device:file:/filename/with/key

Perhaps safe, if /filename/with/key cannot be read by an attacker.

> * --key /dev/device:string:the-actual-key

Rather dangerous, as an attacker reading /proc/NNN/cmdline can get at 
the actual key. But useful for testing.

Qemu's solution was more complex - in addition to allowing plaintext 
keys (for testing), and filenames containing plaintext keys (whether in 
UTF-8 or base64 form), it also includes ways to pass keys that are 
themselves encrypted by a shared key, thus making command line passing 
safe. Qemu's filename solution also has a nice hack: anywhere that 
/path/to/filename works for passing something in the filesystem, 
/dev/fdset/NNN can also be used to pass in something via a file 
descriptor (inherited from the parent process or previously passed via 
SCM_RIGHTS).  So when libvirt wants to pass multiple secrets to qemu, it 
pre-creates a single shared key stored in a temporary file, passes that 
file in by fd, and then uses that key to encrypt everything else passed 
on the command line, so that it only needs one file/fd rather than one 
per key.

https://git.qemu.org/?p=qemu.git;a=blob;f=include/crypto/secret.h;h=edd0e13236#l34

I won't say that you have to repeat qemu's complexity on secret 
management, but it is food for thought on whether your design is 
flexible enough.

> this way it is possible to pass all the credentials needed for the
> specific devices to open, with no risk of conflict with stdin, and also
> in a secure way (when using the "file" way).
> 
> On the technical side: this adds a new "key_store" API for the C tools,
> making sure it is used only when needed.  Partially mirror it also for
> the OCaml tools, although there will be a conversion to the C API
> because the decryption helpers used are in the common C parts.
> ---

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org