unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: Ellen Papsch <ellen.papsch@wine-logistix.de>,
	Alex Griffin <a@ajgrf.com>,
	guix-devel@gnu.org
Subject: Re: Unencrypted boot with encrypted root
Date: Wed, 08 Apr 2020 09:22:29 -0700	[thread overview]
Message-ID: <875zea3q2i.fsf@ponder> (raw)
In-Reply-To: <6fc66a2a3f3cd71febb16bab2a0aeb65b6fdd147.camel@wine-logistix.de>

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

  parent reply	other threads:[~2020-04-08 16:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02  8:59 Unencrypted boot with encrypted root Pierre Neidhardt
2020-04-03 15:32 ` pelzflorian (Florian Pelz)
2020-04-03 15:44 ` Ellen Papsch
2020-04-03 16:13   ` Pierre Neidhardt
2020-04-03 17:16     ` Ellen Papsch
2020-04-03 19:56       ` Guillaume Le Vaillant
2020-04-04  9:02         ` Pierre Neidhardt
2020-05-17 15:39         ` Pierre Neidhardt
2020-05-20  8:49           ` Guillaume Le Vaillant
2020-05-20  9:42             ` Pierre Neidhardt
2020-04-03 19:44   ` pelzflorian (Florian Pelz)
2020-04-04  8:12     ` Ellen Papsch
2020-04-04 10:18       ` pelzflorian (Florian Pelz)
2020-04-06 12:00         ` Ellen Papsch
2020-04-07  9:46           ` Ludovic Courtès
2020-04-07 11:34             ` Ellen Papsch
2020-04-07 20:19               ` Ludovic Courtès
2020-04-08 12:37                 ` Ellen Papsch
2020-04-07 15:05             ` Alex Griffin
2020-04-07 16:47               ` Vagrant Cascadian
2020-04-08 12:25                 ` Ellen Papsch
2020-04-08 15:07                   ` Alex Griffin
2020-04-08 16:22                   ` Vagrant Cascadian [this message]
2020-04-08  7:57               ` Pierre Neidhardt
2020-04-08 12:19                 ` Alex Griffin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875zea3q2i.fsf@ponder \
    --to=vagrant@debian.org \
    --cc=a@ajgrf.com \
    --cc=ellen.papsch@wine-logistix.de \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).