On 2020-04-08, Ellen Papsch wrote:
> Am Dienstag, den 07.04.2020, 09:47 -0700 schrieb Vagrant Cascadian:
>> On 2020-04-07, Alex Griffin wrote:
>> > So we can put the key in its own initrd (outside of the store)
>> > 
>> 
>> I believe it's also possible for grub to provide the key
>> derived/decrypted from the passphrase entered at run-time
>> 
>
> These may be dangerous waters. The key file in initrd is like a house
> key under the mattress. A malicious process could look in the well
> defined place and exfiltrate the key. Think state trojan horses. A
> random name would not suffice, because other characteristics may help
> identifying the file (i.e. size).

The key for a LUKs volume is exposed in the running kernel and a
compromised root account can exfiltrate it... 


> Regarding passing on the key, you mean the master key? I don't know if
> it's possible. If it's documented and recommended, I'd say go for it.
> But keep in mind this is crypto we are talking about. If it's something
> hacky we're straying from the path and may be inadvertently opening up
> security holes. A security guru analysis would help.

It would reduce the attack surface by not asking for the passphrase
twice. You *have* to to it once from grub (presuming encrypted /boot),
so it's simply re-using the unlocked key...


> I think* Guix would burden itself too much with secrets. It's something
> for the user and the installer should just make it more convenient,
> with a nudge to a more secure setup. The key file should be stored in a
> user specified location, preferably a pen drive (which is otherwise not
> used). It can be removed, so no read can occur by arbitrary processes.
> A passphrase should be added as backup.

No need to store the key file in anything but ephemeral ram, ideally
where it wouldn't be swapped to disk, in the running kernel...


I'll look into the actual implementation of what I'm talking about
rather than rambling on further about theoretical possibilities.


live well,
  vagrant