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
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
