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

On 9/19/18 5:37 AM, Pino Toscano wrote: 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]). Perhaps safe, if /filename/with/key cannot be read by an attacker. 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=edd0e... 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. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org