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=edd0e132... 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